Re: [Bug-tar] dist tarball contains hardlinks

[Dimitrios Apostolou]

On Tue, 27 Jan 2015, Pavel Raiskup wrote:
> On Monday 26 of January 2015 12:12:09 Dimitrios Apostolou wrote:
> > On Fri, 23 Jan 2015, Pavel Raiskup wrote:
> >
> > > On Friday 23 of January 2015 15:45:57 Dimitrios Apostolou wrote:
> > > > Thank you Joerg. If so then it is an issue that must be fixed in
> > > > automake, which is the reason I cross-posted to both projects, because I
> > > > am not sure which one should be changed!
> > >
> > > What solution you exactly propose?  Note that 'h' tar option is used for
> >
> > Maybe adding --hard-dereference? That's how I worked around the issue at
> > least.
>
> From the automake POV, this is not standardized option (could be used only
> for GNU tar if present though).

You are right. I /thought/ I had resolved the problem by exporting 
TAR_OPTIONS=--hard-dereference. Unfortunately the problem persists, "make 
dist" fails on RHEL4 for example because tar sees this unrecognized 
option.

> > > dist from Y1996 commit [1] and its removal is unlikely.  It is quite
> > > portable and it, as the "default", works for many packages.
> >
> > It has been there since 1996, so the legacy behaviour of tar has been
> > battle tested. However the new behaviour (hard links in place of
> > symlinks) is probably only tested for a couple of years,
>
> Truth.  The new behavior is in tar from 1.24.  However, if we fixed this
> in tar, GNU tar v1.24 to v1.28 still would not able to mimic the old
> behavior.

I believe my only choice at this point is to forbid "make dist" if tar is 
detected to be old (less than 1.29), and keep doing --hard-dereference. I 
open to new ideas though. :-)

> > Using "tar-ustar" format for distribution you are supposed to raise some
> > of the limits of the "v7" tar format but retain portability. Indeed, the
> > length limit for regular files used to be 256 characters [2], and since
> > all symlinks were stored as files that was universal. Now that symlinks
> > are stored as hard links, the limit is 100 characters for those, thus
> > I've hit this problem.
> >
> > [2] http://www.gnu.org/software/tar/manual/html_section/tar_68.html
>
> Yes, thanks - I see now.  In ustar link name must fit into 100 characters
> and the file path can be theoretically max 256 (if it is splittable
> correctly into prefix/name).
>
> You seem to have *directory* in some distribution sensitive variable,
> like:
>
>  # Directory contains 'file' and 'link -> file'.
>  EXTRA_DIST = directory
>
> .. Because if you had:
>
>  EXTRA_DIST = directory/file directory/link
>
> then automake (via 'cp -p') would follow the link for you.  In case of
> directories (before the actual 'tar ch' happens) automake copies the
> directory recursively by 'cp -fpR' [2] into temporary directory.

I don't think this solution is worth the trouble in my case, since the 
directory included has a deep and complex structure (hence some files 
surpass 100 characters).


Thanks,
Dimitris


> Could we add '-L' option to this cp call (dist target is not supposed to
> be portable to everywhere and -L is POSIX)?  Obviously, the archive bloat
> is not something automake tries to avoid.
>
> Anyway, I don't feel the handling of symbolic-links this way is correct.
> Don't we wan't to use something like $LN_S [autoconf manual] in such
> cases?
>
> [1] https://lists.gnu.org/archive/html/bug-tar/2011-01/msg00000.html
> [2] 
> http://git.savannah.gnu.org/cgit/automake.git/tree/lib/am/distdir.am?id=6357a630dc#n193
>
> Pavel