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

[Nicholas D Steeves]

Hi Sebastian,

Sebastian Ramacher <sramacher at debian.org> writes:
>
> On 2022-02-21 14:27:05 -0700, Nicholas D Steeves wrote:
>> 
>> 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.
>

In general, yes, I agree, but I don't think I can justify a lock-step
dependency for a bug that appears to be subtle enough that no one has
reported it for five years.  To be honest, I'm looking for some kind of
mechanism to either trigger a rebuild or alert that a rebuild is
necessary--that is, if the best solution is on the buildd side.  That's
an aside though.  Read on to learn how you've inspired me otherwise.

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

I agree 100%, and am definitely thinking about those users!  What types
of triggers do you mean?  Do you mean that hydrogen-drumkits should
install the drumkit.xml files to an out of the way location, and then
use a dpkg trigger to refresh them and install them to the expected
run-time location with whatever version of hydrogen is currently
installed?  I confess I hadn't considered this until you suggested it.
In this solution, a bin:hydrogen-drumkits-xml pkg doesn't appear to be
needed to be kind to users on metered connections, and I like that!

There are two problems with this solution that I don't (yet) know how to
address:

1. The drumkits package would need to use a trigger mechanism like
foo-dkms packages.  eg: When the kernel-image is upgraded, it triggers a
rebuild of foo-dkms.  It appears that dpkg triggers would solve this,
and I'm excited to learn more and level-up my packaging knowledge/skills.
Please ACK if this is the case :-)

2. What is the modern alternative to using a maintscript to clean up
those refreshed files?  The out of the way copies would be owned by the
package, but the ones in the expected run-time location wouldn't.
Alternatively, if I shipped two copies of the drumkit.xml files then
`dpkg -V` would fail for all paths that referred to the refreshed copies.
It feels like there should be something like
'debian/bin-foo-pkg-name.paths' that defines paths owned by the
package--and more importantly cleaned up when the package is removed.


Thank you,
Nicholas