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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
