Hi Sebastian, Sebastian Ramacher <sramac...@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
