Bug#514016: options for fixing

[Bdale Garbee <bdale@gag.com>]

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?

Adding a Debian-specific option to tar would certainly not be my first
choice.

Bdale