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

Making trixie debootstrap-able again?



Hi,

I'm not sure how we reached this situation but there are a bunch of
packages in trixie that are not in a suitable state. To reproduce, a
simple `debootstrap trixie /tmp/trixie` on amd64 is sufficient.

Note: I've limited my exploration to amd64, which kept me busy already…

An obvious first problem is coreutils, which picked a Pre-Depends on
libssl3 (not the t64 one), which… disappeared from testing between the
2024-04-24 14:58:20 and 2024-04-24 20:51:02 (checked by looking at
Packages.gz for amd64 via snapshot.debian.org).

The coreutils binNMU is hardly new, as it appeared via unstable in
January, and was already in testing by April 1st (I didn't check earlier
than that). Therefore I'm quite baffled to see libssl3 happily disappear
from testing while we still have stuff that Pre-Depends on it?!

Checking britney, I suppose this is a result of the following hint:

    # 2024-04-23; done 2024-04-25
    # help some t64 packages migrate
    […]
    force-hint openssl/3.2.1-3

Anyway, I wanted to see if suggesting (I wouldn't go as far as requesting
because I'm really not sure this would be the right course of action, more
details below) a new binNMU of coreutils within testing would be
sufficient to make trixie debootstrap-able again, I built a modified
repository, and try debootstrap against it, only to find more problems:
 - util-linux binaries (e.g. fdisk) depend on libreadline8, which is gone.
 - iproute2 depends on libtirpc3, which is gone.

I guess the reason is similar, the former I tracked down to the same block
of hints as before:

    # 2024-04-23; done 2024-04-25
    # help some t64 packages migrate
    […]
    force-hint readline/8.2-4

The latter I tracked down to thisone:

    # 2024-04-23; done 2024-04-26
    # get t64 unstuck
    urgent libtirpc/1.3.4+ds-1.3
    force-hint libtirpc/1.3.4+ds-1.3


Again, I have absolutely no clue regarding the best course of action at
this point. I can't even perform clean builds to check what a binNMU in
testing would look like, as I can't debootstrap a clean environment (and
therefore only tested rebuilds in an existing, devel-oriented, unclean
trixie chroot).

Seeing how some packages, e.g. coreutils, have DEP-17 changes staged in
unstable (since 1.5+ month), I'm definitely not advocating for pushing
them into testing as a quick or easy fix for those issues.


I'm not sure whether you're keeping track of things that break when
force-hinting but if you were aware of the resulting breakages already,
some kind of heads-up would have been nice…


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature


Reply to: