[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#514016: options for fixing


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

Thomas Viehmann, http://thomas.viehmann.net/

Reply to: