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

[Andrea Bolognani]

On Mon, Jun 03, 2024 at 11:11:42AM +0200, Helmut Grohne wrote:
> On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote:
> > 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.

I personally consider backportability a nice-to-have, not a strict
requirement. Christian cares about it more, since he's building
libvirt for fairly old Ubuntu releases. I've added him to the
conversation so he can weigh in.

If backports to Debian 12 and Ubuntu <24.04 are really not feasible,
that's good news in my book, because it means that we can drop a
bunch of compatibility code.

> > 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?
> 
> [...] 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.
> [...] I fear there is not much more that we can do here than
> promise supporting you in the event of fallout.

That's a reasonable stance and level of commitment.

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

I'm sorry, but this still doesn't make a whole lot of sense to me.

If I performed the move today and got a thumbs-up from dumat, that
would only tell me that the change *on its own* is fine. But we also
know for a fact that restructuring the package might introduce file
loss scenarios, so what use is that really? It just provides a false
sense of security.

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

The time and energy I can dedicate to Debian work is unfortunately
limited. I've been focusing all of it to restructuring the package,
and I've made fairly solid progress so far. It will take a while
longer before it reaches a state where other people can look at it
though.

-- 
Andrea Bolognani <eof at kiyuko.org>
Resistance is futile, you will be garbage collected.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20240609/c2367ebe/attachment.sig>