Re: /usr-merge and filesystem bootstrap

[Helmut Grohne <helmut@subdivi.de>]

Hi Aurelien,

On Fri, Sep 15, 2023 at 12:02:35AM +0200, Aurelien Jarno wrote:
> Answering for the glibc package.

Thanks.

> On 2023-09-12 20:15, Helmut Grohne wrote:
> > Once the Priority:required set only has that exception set left
> > unconverted, I will prepare patches for the entire exception set and
> > upload it coherently in one dinstall window.
> > 
> > That exception set is:
> >  * base-files
> >  * bash
> >  * coreutils maybe
> >  * dash
> >  * libc6
> >  * util-linux
> 
> Do you mean you plan to upload source+binaries for all the above
> packages and for all architectures? How do you plan to handle ports
> architectures? 

My initial idea was doing source-only uploads and letting buildds
perform all of the builds. Of course that leaves the possibility of
buildds producing their packages "late" for the next dinstall. If that
happens, the relevant architecture will fail debootstrap unstable. That
is unfortunate, but it does happen occasionally and I think it is a
reasonable risk to accept here. Once all relevant builds are done,
debootstrap will work again. There are a number of things I can do to
minimize the risk. For one thing, I can ask DSA when the cronjob for
updating buildd chroots happens and align the uploads closely after such
a cronjob. For another, I can coordinate with the buildd people and ask
for help (e.g. prioritizing builds) on their side. Then I can mail
d-devel and announce a concrete point in time asking developers to not
upload packages on that particular day (e.g. using the delayed queue) to
temporarily reduce the buildd load. Quite probably, debootstrap will
temporarily break on some architectures. I hope that this is acceptable
and that minimizing the downsides is good enough.

Does that answer your question?

> >  * Are you fine in principle with me NMUing your package after having
> >    reviewed the promised patch?
> 
> Yes, with the condition that help is provided to fix the bugs resulting
> from moving files from / to /usr in the glibc packages.

It is sad to see that this no longer goes without saying. Yes, I will
actively look for possible fallout and allocate time for dealing with
it.

> >  * Do you readily see any flaw in the proposed transition already?
> 
> I haven't looked at the details besides the changes you described above.

Thank you. We'll get into details once there are patches.

Unfortunately, testing patches right now is difficult, because this work
depends on all other (required) packages having been converted, which in
turn is blocked in buildds being merged. Hoping that this is less work
if done later, I've prioritized other matters for now and reach out to
you now as a means of informing and gathering consent.

There will certainly be a few more mails about this and there will be
time after me having sent patches and provided details on how I tested
them.

Helmut