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

Bug#978636: move to merged-usr-only?



On Tue, Jan 26, 2021 at 09:56:46AM +0000, Simon McVittie wrote:
> Oh, I see. So when you say "both" in 1a, you're referring to the overall
> system - like the fact that we have both /bin/bash and /usr/bin/perl.

Yes.

> I don't see how we can force all packages to only ship files in /usr/*
> (your 1b), except by either *first* moving to merged-/usr-via-aliasing

Which is the easy part.  We say: other systems are not longer supported
after date X.  Otherwise we will never get it done.

> * bash and libc6 are Essential
>   (so are other packages, but these two are enough to demonstrate my point)
> * bash has traditionally shipped /bin/bash, and this is part of its
>   Essential interface (other packages ship #!/bin/bash scripts)
> * libc6 ships /lib/ld-linux.so.2 and other architectures' equivalents,
>   and this is part of its Essential interface
>   (other i386 packages have ELF interpreter /lib/ld-linux.so.2)
> * Essential packages are required to be functional after being merely
>   unpacked, not configured (otherwise debootstrap can't work)
> 
> So if we unpack bash and libc6:i386, but do not configure them, /bin/bash
> and /lib/ld-linux.so.2 must exist in the resulting chroot.

Before unpacking those packages, both /bin and /lib symlinks must
already exist, because it's past the cutoff date of non-aliased support.

> However, if that chroot is in layout 2a or 2b, and bash's filesystem tarball
> contains ./usr/bin/bash, then its Essential interface is incomplete:
> there will be no /bin/bash symlink until the package is configured
> (maintainer scripts are run).

Option 2 doesn't provide us any benefit.  The world already implemented
option 1.

> I agree that your 1b is preferable *eventually*, but I think your 1a is
> necessary as a stepping-stone to get there.

We are already effectively at 1a.  So we need to decide if we want 1b to
fix the fallout.

> The only other option that I can see is for dpkg to gain the ability to
> populate what we might call the "mergeable" directories (/bin, /sbin,
> /lib*) in a purely declarative way, during unpack.

No, because we want to support /usr only systems or snapshots, where /
is populated on first boot.  That's where the world is going.

Bastian

-- 
Earth -- mother of the most beautiful women in the universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1


Reply to: