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