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

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)



On May 17, Helmut Grohne <helmut@subdivi.de> wrote:

> Given the feedback, I am convinced that changing PT_INTERP is a stupid
> idea regardless of whether it is technically feasible. There must be a
> better way. Let's step back a bit.
Me too, I was never persuaded.

>  4. Change the bootstrap protocol. In essence, this has been attempted
>     in debootstrap by creating these symlinks prior to unpack, but no
>     consensus has evolved around this approach yet. The category is
>     wider though and generally requires changes to all bootstrapping
>     tools.
I think that this is being dismissed too easily, mostly because the
mmdebstrap maintainer has been fighting it due to a philosophical 
preference.

> Moving on to category 4 feels rather obvious, especially because work
> has been done there in debootstrap. The approach in debootstrap however
> is one that I see as a dead end, because it causes us to maintain this
> code multiple times. It's the number of derivatives times the number of
> bootstrap tools and that doesn't scale.
But the code is trivial. It is currently more complex than it is needed 
in debootstrap only because initially it needed to support the biarch 
libc packages, but since nowadays they create the top level symlinks 
themselves then it can be made as simple as:

        for dir in bin sbin lib; do
                ln -s usr/"$dir" "$TARGET/$dir"
                mkdir -p "$TARGET/usr/$dir"
        done

Indeed, usrmerge does not have any architecture-specific knowledge 
anymore.

> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. In particular,
> making architecture bootstrap become chrootless would likely be a
> generic solution to this and other problems.  However, any change needs
> to propagate to a stable release in all bootstrapping tools.  Therefore
> we cannot reasonably finish the transition before forky.  This makes
Why not?

> So what's left is category 1. I looked into what the minimum set of
> files to be retained could be. To do that end, I moved everything and
> then reverted as much as was needed to make bootstrapping work.
>  * /lib64/ld-linux-x86-64.so.2 (hopefully obvious)
>  * /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (link target)
>  * /bin/sh (hopefully obvious)
>  * /bin/dash (link target)
Interesting approach. If it is so much simple, why are you not persuaded 
that it could be a good solution until the bootstrapping tools are 
updated?

>  * /bin/bash (usrmerge runs ldd, which is a #!/bin/bash script)
>  * /bin/more (update-alternatives doesn't like its absence)
>  * /bin/cp (unless usrmerge stops hard coding its path)
These can be easily fixed, maybe the ldd issue too.

> The other major takeaway is that a significant
> chunk of the problems mentioned in this mail cannot be fixed by
> modifying dpkg only.
Agreed.

-- 
ciao,
Marco

Attachment: signature.asc
Description: PGP signature


Reply to: