Bug#514016: options for fixing

[Andreas Barth <aba@not.so.argh.org>]

* Bdale Garbee (bdale@gag.com) [090922 19:14]:
> On Thu, 2009-02-05 at 18:20 +0100, Thomas Viehmann wrote:
> 
> > just as an exercise what might be done to fix this:
> > It would seem that the options are
> > - not fix it (for now),
> > - find something in current tar that works (I didn't),
> > - switch off tar,
> > - try to do something with tar
> >   (new upstream - vs. release: ugh - has a "apply to symlink target"
> >    --transform flag, but that also might need post-processing of
> >    symlinks at end of bootstrapping),
> > - try to do some ld-preload(?) trickery for changing the way symlinks
> >   are read,
> > - try to find some way to chroot before calling tar, one possibility
> >   would be copying required files to some temp CWD, make tar look there
> >   for the libraries, chrooting to the target and calling tar from (the
> >   unchanged) CWD,
> > - add chroot option to tar (see patch).
> 
> How about just fixing the offending package to use a relative symlink,
> like /lib64 -> lib?  This is well within policy since they're adjacent
> objects in the same directory, and is less likely to break things or be
> a pain to maintain over time than any of the options above.  I can't
> think of any negative consequence to this change, offhand?

I don't see a case where a package needs a absolute symlink. If there
is no use case, it'd be easy to just stop such packages in dak from
entering the archive.


Cheers,
Andi