Hi, thanks for your replies. Again, this is mostly because I needed some idle occupation and am not into sudoku. Apologies for presenting it a way that looked like a proposal.
Bdale Garbee wrote: > 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? Well, having 1000 maintainers do the right thing is difficult, as proven by the release process. > Adding a Debian-specific option to tar would certainly not be my first > choice. Other options do exist, my list probably is not exhaustive, but I would think that they cost a lot of code with a lot of opportunity to add bugs where things work now and it might be interesting to have an upper bound for how involved a minimal fix is. Thinking on a larger scale, what we actually want to do here is unpack a tarball into a chroot. I venture that this is a reasonable use case of tar and that it might just be possible to try to have upstream agree to have such an option in principle so that there is a plan to get rid of the debian-specificity of the option. Bastian Blank wrote: >> - switch off tar, > I intend to replace tar with a custom unpack routine in cdebootstrap. TBH, I'm not that impressed by the implementation of ar (or a subset) in dpkg and am not sure that reimplementing tar extraction it is a good path to take when I would think that an option for tar to do the right thing (whether internally munging symlinks when resolving paths or using chroot) might have a general use beyond bootstrapping Debian systems. >> - 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), > > What would dpkg do with the symlinks in the the unpack phase? I have not tested it, but I would venture the same thing (calling tar, ergo having the same problem) from when I last looked at it. >> - try to do some ld-preload(?) trickery for changing the way symlinks >> are read, > fakechroot have to do this someway, but I was unable to grok that code > yet. Well, you'd have to intercept all the relevant calls (for dereferencing/reading symlinks). Seems doable, but IMO tar would be the better place. But if the masses want funny business, so be it. ... >> - add chroot option to tar (see patch). > This is a root only option. Yes. It was my impression that (c)debootstrap are supposed to be called by root. At least I always used to call them as root when I was a developer. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
