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

Re: tech-ctte: more on merged-/usr



On Mon, 18 Jul 2022 at 13:03:36 -0700, Tianon Gravi wrote:
> Hopefully I'm not too OT (please feel free to tell me if so! [1] would
> be an appropriate place to continue with more discussion on the topic)
> but another angle to this is the container images.
> 
> [1]: https://github.com/debuerreotype/docker-debian-artifacts/issues/131#issuecomment-900591334
> 
> They're currently *not* merged-/usr specifically because their usage
> is in a gray area between user and build and we didn't want to break
> the latter -- I'm guessing this means that for Bookworm, they should
> technically stay in the "unsupported" configuration for the lifetime
> of the release? /o\

That would seem pretty bad to me. Official or pseudo-official Debian
containers should be set up to be in a supported configuration.

However, I do see your point about these containers being in a grey area
between user and build, and there is a risk (a relatively small risk at
this point) that if people are building packages in a debian:bookworm
Docker container, the resulting packages will only work on merged-/usr
systems.

At the time I commented on docker-debian-artifacts#131, I think it would
have been premature to /usr-merge these images, but now that I've raised
the known misbuilt-on-merged-/usr bugs to RC, I think it's time to consider
applying merged-/usr anyway.

I'd appreciate input from the rest of the TC, but I think this is what I'd
do if it was up to me:

1. apply merged-/usr to suites > bookworm in debuerreotype, perhaps
   something like this:
   - in general stop passing --merged-usr *or* --no-merged-usr to
     debootstrap by default, so debootstrap will decide automatically based
     on suite
   - as a special case, add --no-merged-usr for buster and bullseye, for
     continuity (debootstrap defaults to merged-/usr for those suites, but
     their Docker containers have traditionally been unmerged), and
     also bookworm in the short term
   - `debuerreotype --[no-]merged-usr` continues to be an override

2. wait for the proposed migration step (init-system-helper Depends
   usrmerge) to reach testing

3. extend merged-/usr to debuerreotype suites >= bookworm by removing
   bookworm's special case in debuerreotype

Does that sound reasonable to everyone? Starting to /usr-merge debian:sid
before debian:bookworm would give you a chance to spot any showstopper
issues.

    smcv


Reply to: