bug#19616: [Bug-tar] dist tarball contains hardlinks

[Pavel Raiskup]

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).

> > 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.

> and I've seen complaints online.

There were posted some complaints here on the list, but these seem to be
not so serious to revert that behavior or add yet another option (like
mentioned in [1] thread).

> > What is not clear to me also is your motivation to change GNU tar to
> > behave differently, or to change something so old in automake.  IMO,
> > the
>
> 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.

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