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.

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.


Regards,
Nicholas

Hi Nicholas

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

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.

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

Hi Sebastian,

Sebastian Ramacher <sramacher@debian.org> writes:

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.

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

Hi Nicholas

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.

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

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