Bug#1006247: Upgrade drumkit.xml files using hydrogen's new utility functionality

[Sebastian Ramacher]

Hi Nicholas

just a warning: I don't have any clue about hydrogen.

On 2022-02-21 14:27:05 -0700, Nicholas D Steeves wrote:
> Subject: Upgrade drumkit.xml files at build-time using Hydrogen's new utility functionality
> Package: hydrogen-drumkits
> X-Debbugs-Cc: sten at debian.org, Alessio Treglia <alessio at debian.org>, Free Ekanayaka <freee at debian.org>, IOhannes m zmölnig (Debian/GNU) <umlaeute at debian.org>, Jaromír Mikeš <mira.mikes at seznam.cz>,
> Version: 2017.09.19~dfsg-1
> Severity: normal
> Owner: sten at debian.org
> 
> I've CCed all Uploaders and am requesting that anyone who is no longer
> interested in this package reply with something to the effect of "yes,
> please drop me from Uploaders"--or just edit control in the git repo, as
> preferred!  Jonas, I remember you asked to be dropped from src:hydrogen,
> and am CCing you because I'd appreciate your perspective on this
> problem.  As far as I can tell this will be the last issue you will hear
> from me about Hydrogen!  Sorry I missed this when adopting the main
> package :$ Likewise, I'd appreciate the perspective of anyone else on
> the following issue:
> 
> I recently learned from upstream that drumkit.xml files are now
> usually upgraded in $HOME when a newer version of Hydrogen is
> executed.  Of course, that won't work in Debian (drumkit files in
> /usr), so I opened an issue upstream requesting that the drumkit
> upgrade function is exposed on the command line; it's fixed there
> (albeit seemingly without support for relative paths, which may be
> needed on buildd), and merging the patch set into Debian is pending.
> I've of course already begun locally testing it.
> 
> Since bin:hydrogen-drumkits is a somewhat large package, I think that it
> might be a good idea to introduce a bin:hydrogen-drumkits-xml package
> that has some kind of dependency on the latest version of hydrogen,
> because it seems to me that more often than not Hydrogen will emit
> warnings whenever the version used to generate drumkits.xml doesn't
> match bin:hydrogen's version...usually this will be cosmetic, I
> think...except when it's not, and it doesn't make sense to me to
> dedicate developer time to tracking genuine schema incompatibilities.
> Any objections or alternative solutions would be very much welcome!  In
> particular, I wonder if reprobuilds could be leveraged as a kind of
> canary, where trivially scanning the debdiff would make it clear whether
> an upgrade/upload of hydrogen-drumkits-xml was needed.
> 
> Alternatively it might also be a good idea to introduce a drumkit.xml
> autopkgtest to src:hydrogen to block migration of bin:hydrogen until the
> drumkit.xml package has also been updated in sid.  If someone has a good
> regex heuristic that could reduce false positives and unnecessary
> blocks, that'd be much appreciated!  I'm learning as I go and if working
> along will probably defer this optimisation to a later date.

While autopkgtest are always a good idea, note that the autopkgtest may
prevent hydrogen from migrating to testing, it doesn't prevent users
frmo installing incompatible versions. For that you need tight enough
dependencies. At that point, the dependencies alone will already ensure
that only compatible packages migrate to testing.

> Oh, the proposed bin:hydrogen-drumkits-xml would be mostly to save user
> and mirror bandwidth when tracking sid and testing.  I don't think that
> it makes much difference for Debian infra disk space, and were it to
> make a big difference, it seems that there's consensus that disk space
> is now cheap.  It looks to me like a src:hydrogen-drumkits-xml (or
> rebuilding them on the src:hydrogen) side isn't possible due to a
> chicken egg problem for the drumkit.xml file when introducing new
> drumkits to src:hydrogen-drumkits.

Depending on how stable the tool is that generates the drumkit.xml
files, have you considered generting them in a trigger? Storage space
may be cheap, but if the drumkits are large enough to be a concern for
metered connections, I don't think users will appreciate the download of
a large package for an update of a version in an XML file.

Cheers
-- 
Sebastian Ramacher
-------------- 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-multimedia-maintainers/attachments/20220223/47deaf9e/attachment.sig>