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

[Helmut Grohne]

Hi Andrea,

I think Michael and Chris already said most of the relevant things, but
Chris asked me to chime in.

On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote:
> 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.

Your worry is reasonable. However, deferring these changes is going to
make it worse as we have less time to handle possible breakage. The way
to avoid the 2) scenario is to upload to experimental (with upgrade
problems), have dumat detect all the issues, fix them there and only
then (once the analyzer is happy) move to unstable.

> 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.

I fear that you are between a rock and a hard place here. The time64 and
/usr-move transitions very much are not backportable in a sane way. In
particular, the existence of a P1 problem (as you suggest there will be)
rules out dh_movetousr. It gets even worse though. If you backport,
you're supposed to move units back to aliased paths (due to the file
move moratorium still being in place for bookworm and due to bookworm's
debhelper not adding maintainer scripts or moved units). So when you
upgrade from bookworm-backports to trixie (in a distant future), you
have a new upgrade path and the trixie package will need even more
mitigations. Yes, this is suboptimal.

> 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?

Ideally, your restructuring upload goes to experimental, so all of
experimental users have broken systems then. When dumat reports an
issue, I'll investigate the cause and propose a solution (patch) and
file an rc bug. That tells you that you're not good to move to unstable
as is and gives the two of us time to discuss solutions and the
integration into the package.

> 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. We're enumerating badness here. We're limiting the damage that has
already been done. We've looked at lots of problems and tried to
identify as many as possible problems and specifically test for known
problem categories. False negatives are possible and have happened
indeed. But then, what we have makes it fairly unlikely for users to
practically experience those problems. The goal definitely is to not
have any file loss in bookworm -> trixie nor testing/unstable upgrade
scenarios. The guarantee you are looking for does not exist, but we're
making a good effort at it and I believe that we have a fairly good
track record of actually supporting this transition when problems arise.
For instance, the diversions in molly-guard turned out to be way more
difficult to mitigate than originally anticipated and while it took
quite a bit longer, we now have a working solution. Likewise, when
piuparts or the debian-installer was broken, we sent patches rather than
disappearing. I fear there is not much more that we can do here than
promise supporting you in the event of fallout.

> 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.

Interestingly, my instinct (and that of Michael and Chris) tell exactly
the opposite story. Many of the /usr-move issues are interaction
problems between multiple packages. When we look for problems, we don't
look for recent history, but use a static analyzer that precisely pin
points where to look. The earlier we move stuff, the more capacity we
have for keeping up the support promise.

So yes, I also recommend moving stuff to /usr as soon as possible and in
particular without the restructuring changes (as that allows us to
analyze the move already).

What I don't have is a good answer about backports. In the face of P1
problems, backports are difficult to get right. Indeed, doing a backport
now and then saying "no more bookworm-backports after /usr-move and
restructuring" can be a sensible thing, but you pay with less support
from us in the event of fallout.

I'm also happy to have a look at how you plan to restructure libvirt and
tell you where I expect problems before you actually upload. Or better
still, you upload to experimental. Just get it done sooner rather than
later.

In the end, all packages shipping files in aliased locations will have
an rc bug and get kicked out of trixie or being NMUed. I expect that you
do not favour either of these.

Helmut