Hi release team and Aurelien, Let me establish a bit of context for the benefit of new readers (aka release team). The bug here is about guestfs-tests being broken on a partially upgraded system. If you combine a bookworm with a trixie libc6 (and no trixie base-files), guestfs (probably supermin) manages to construct a rootfs that lacks the aliasing symlinks (e.g. /lib64 -> /usr/lib64 is missing) and hence the resulting guest fails to boot.
On Sun, Jul 28, 2024 at 04:10:14PM +0100, Aurelien Jarno wrote: > On 2024-07-27 10:46, Helmut Grohne wrote: > > The failure in libguestfs-tools is a bug there in my opinion. It uses > > the host system to construct a VM environment and fails to account for > > the aliasing links created by usrmerge or debootstrap not recorded in a > > packaging database. This is unfortunate, but not a bug in libc6 as it > > correctly explains its requirements (via an implicit dependency on > > essential packages). > > Do you mean we could reassign the bug to libguestfs-tools? And get solve > it there instead? Yes. I argue that guestfs makes unreasonable assumptions about Debian packages. In a pre-trixie (and partially upgraded environment), it needs to install usrmerge or usr-is-merged (and handle the aliasing links manually) for its guests but apparently it doesn't do that. A weaker solution would be for guestfs to declare versioned breaks for libc6 and base-files ensuring that both are upgraded. That still leaves a broken guestfs if you do a partial upgrade of bookworm to trixie, but I think that situation is the lower cost than having libc6 declare versioned Breaks for base-files indeed. apt will be faced with fairly complex ordering issues due to the time64 transition and I'd like to avoid adding more constraints than strictly necessary here. > > I argue that the risk of running a partially upgraded system and running > > libguestfs tests is fairly low at this time as both packages have > > migrated and trixie-based images typically have been updated (even in a > > monthly cadence) to include all relevant changes. Hence, I argue that at > > this time the cost of including this Breaks outweighs its benefits. > > > > Do you agree with this reasoning? > > I am also fine to just ignore the bug, but I don't want it to come back > at a later stage. Should we maybe get an agreement with the release team > that it is not considered as a bug? I hear you. Hence I added the release team to Cc to get some confirmation. The question at hand is whether libc6 should declare Breaks: base-files (<< trixie) or not. It currently does for guestfs tests, but I argue that this negatively impacts apt's solution space for bookworm to trixie dist-upgrades. I've made my case and if everyone else agrees that having these Breaks is better, I'll shut up as this is not that important in the grand scheme of things. It's a trade-off either way. Helmut
