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

[Sebastian Ramacher]

Hi Nicholas

On 2022-02-23 05:49:09 -0500, Nicholas D Steeves wrote:
> 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.

The best way to trigger a rebuild is a lock-step dependency in this
case. From a release point perspective, this is easier to detect than an
autopkgtest where we have to first decipher the failure.

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

Right, exactly like that … or the triggers of libvlc-bin that generates
the plugin cache which is version dependant and plugin dependant.

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

There is no "modern" replacement of maintscripts for this use cases yet.

(I am unable to follow the drumkit.xml discussion. If that's the thing
generated by the tools via the trigger, why would there be two copies?)

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/20220305/98fa435a/attachment.sig>