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

Helmut Grohne helmut at subdivi.de
Fri Aug 30 20:38:46 BST 2024


Hi Andrea,

On Fri, Aug 30, 2024 at 09:19:08PM +0200, Andrea Bolognani wrote:
> > If you happen to enjoy merge requests originating from the Debian
> > Janitor, you may wrap all the added code like this:
> > 
> > # begin-remove-after: released:trixie
> > #DELETE_PROTECTIVE_DIVERSION#
> > # end-remove-after
> > 
> > This serves both as a human-readable reminder for removing the code
> > eventually, but it also is machine-readable and will make the Debian
> > Janitor propose a MR for removing this code at the desired time. I'll
> > leave it up to you whether you want to add support for this or not. If
> > you do, please wrap all relevant code to avoid a partial removal.
> 
> We've generally strived to maintain wider compatibility than just one
> Debian release, for example with the most recent Ubuntu LTS at the
> very least and possibly some more. So this suggestion, albeit really
> useful, doesn't really apply to libvirt.

I still recommend using the markup in this case, but you may simply bump
it to released:forky at your choice. I guess Ubuntu release names will
also work.

> For preinst, abort-upgrade is called against old-preinst, so this
> doesn't seem very useful. Older versions of the package, by
> definition, will not know about the diversion so there won't be
> anything to clean up in those cases.

I stand corrected.

> Yes, I've just used virtlogd as an example. The other services will
> be handled as well.

Good.

> Yes, I've mentioned the fact that tis was an oversight in a follow-up
> message. I guess you must have missed it :)

Bad timing. My mail took a little longer in transit.

> > > +    if [ -z "$2" ] || dpkg --compare-versions -- "$2" gt "$lastver"; then
> > > +        return 0
> > > +    fi
> > 
> > Please remove this check. For instance, libvirt-daemon-common does not
> > exist in bookworm. Hence $2 will be empty and you'd skip the addition of
> > these diversions when installing libvirt-daemon-common, but they're
> > really needed on such a first installation. What you could check here is
> > the version of libvirt-daemon-system (the package we are moving the
> > units from), but the added value in doing so does not warrant the added
> > complexity in my opinion.
> 
> Right, this is incorrect. Another consequence of very quickly
> sketching out a draft implementation :)
> 
> I disagree on the check being useless in general though. The
> diversion should only be created when upgrading from a version of
> libvirt that was not usr-merged to one that is; when upgrading from a
> version that is already usr-merged, we should do nothing.
> 
> So the correct check should be
> 
>   if [ -n "$2" ] && dpkg --compare-versions -- "$2" gt "$lastver"; then
>       return 0
>   fi

Indeed. If you already are on a moved version, that should work. Please
keep in mind that when doing this, you must not backport libvirt as
bookworm (including bookworm-backports) need to have systemd units in
aliased locations as otherwise debhelper will fail to generate
maintainer scripts. So the $lastver should be the last version that ever
becomes part of any bookworm release. To accommodate security updates, I
recommend changing it to `ge "$firstver"`.

> I'm not familiar with running piuparts locally. If you can share some
> brief instructions on how to do that, I'll happily try things out
> before creating the MR.

You may just pass a .changes file to piuparts and it'll debootstrap into
a directory and clean up behind itself. This will not test upgrades, but
it'll catch the worst of mistakes. piuparts expects to be run as root
though. You may run unstable piuparts without root by wrapping it in

    unshare --user --map-auto --setuid 0 --setgid 0 --mount --pid --fork --mount-proc true

For details refer to
https://salsa.debian.org/debian/piuparts/-/merge_requests/60. Failing
that, just upload to experimental and let piuparts.d.o do it.

> I'll work on implementing and testing this over the weekend. I'll
> update the bug as appropriate.

Looking forward to your update.

Helmut



More information about the Pkg-libvirt-maintainers mailing list