XPost: linux.debian.devel

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)