[Pkg-libvirt-maintainers] Bug#1064126: libvirt: install NSS modules into /usr

[Chris Hofstaedtler]

Hi,

please make sure the usrmerge changes land in trixie well before the
transition freeze.
Now would be a great time.

On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote:
> On Mon, Feb 26, 2024 at 11:38:58AM +0100, Michael Biebl wrote:
> > > > Am 25.02.24 um 19:30 schrieb Andrea Bolognani:
> > > Right there with you. I just don't want to rush things, especially
> > > since AFAIK some really problematic scenarios can be triggered when
> > > paths are canonicalized at the same time as they are moved across
> > > binary packages.
> > 
> > This is correct. Moving files between packages and from / to /usr at the
> > same time corresponds to the file loss scenario described at
> > https://subdivi.de/~helmut/dep17.html as P1.
> > See also
> > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=helmutg%40debian.org&tag=dep17p1
> 
> Note that "at the same time" can mean two things in this context:
> 
>   1) when upgrading from bookworm to trixie;
>   2) when upgrading testing/unstable.
> 
> I'm sure that 1) can be handled correctly, but the prospect of
> causing file loss for 2) by accident is not particularly appealing
> and I'd like to avoid it if at all possible.
> 
> > > Going forward, I will focus all the time I can spend on Debian on
> > > reorganizing the libvirt package to enable modular daemons. I hope to
> > > have at least a rough implementation ready within a few weeks.
> > 
> > I don't think postponing the usr-merge changes helps mitigating any issues
> > since those need to happen for trixie in one way or another.
> > 
> > My recommendation is to upload the current patch in this bug report soon,
> > and do the package re-organisation later  via an upload to experimental.
> > dumat will then pick up any potential issues.
> > See the recommendations in https://wiki.debian.org/UsrMerge
> 
> As I've explained we want to preserve backportability as much as
> possible, which pretty much rules out the current patch. At the very
> least we'd have to use dh_movetousr instead.
> 
> What I still fail to understand, and please bear with me because the
> issue is most likely on my side, is how the fallout from a "bad" file
> move would be dealt with.
> 
> Suppose that I made the usr-merge upload today, and the package
> restructure upload in a month. At that point, dumat would detect that
> file loss could occur, report it and... What then?

Then you get to fix them manually in various maintainer scripts,
hoping they can be fixed.

> Have reliable mitigations been developed for all possible file loss
> scenarios?  Is it guaranteed that such mitigations, when applied,
> will protect from file loss not just the people running stable, but
> also those running testing and unstable?

No. The mitigations are fragile; bugs in dpkg and/or policy have
been discovered. Extensive testing is required for all scenarios you
can envision.
Even then, some things are just not fixable in a reliable manner.

> My instincts tell me that it would be much easier to reason about
> this if the two transitions happened at the same time rather than
> potentially months apart. This is my main concern with applying the
> usr-merge changes when we still don't have a clear picture of what
> the final state of the package will look like.

The best is to have as few file moves as possible in trixie. In
forky, moving files becomes easier again.

Chris