Bug#514016: options for fixing
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/
Reply to: