Hi Nicholas, Dropped one of the bugs from "To:" (leaving only the RFS copied in). On 30/12/2020 00:55, Nicholas D Steeves wrote: > Hi Ross, > > Ross Gammon <rossgammon@debian.org> writes: > >> I have spent some time going through the commit messages. There has >> been a lot of work done! > Yes :-) If I remember correctly, cdbs -> dh, and upstream churn between > prereleases was the worst of it. > > > Will do! The WIP branch is called "rfs-976113-rebase" and I pushed it > just now; it doesn't contain much yet. I will update mentors as soon as > we have an upload candidate (still too many outstanding big issues at > this time). <snip> >> I was wondering why the library packages suddenly appeared. I think if >> it is possible, it is best to stick to the old packages. What >> applications would want to use hydrogen as a library? >> > Hypothetical 3rd party plugins, I think? Unfortunately even with > -DWANT_SHARED=OFF we still end up with libhydrogen-core-1.0.1.a, which > appears to have not been installed in the 0.9.7 series of Debian > packages. I can whitelist and ignore it, but for comparison to other > distributions, OpenSUSE chose to ship the lib: > > https://software.opensuse.org/package/libhydrogen-core0 (for 0.9.7) > https://software.opensuse.org/package/libhydrogen-core1 (for 1.0.1) > > Also, I'm also not sure if there is any practical benefit to > hydrogen-dev (hypothetical plugin development), so I'm wondering if the > headers should not be installed; they weren't installed in the last > release (0.9.7-6). Hydrogen-dev_1.0.1-1_all.deb is only 84KB, so could > be merged into libhydrogen-core-1.0.1. Sebastinas says the -dev package > is arch-specific, and if that's the case it seems like merging the -dev > package into bin:libhydrogen-core-1.0.1 would be reasonable. > > There is something to be said the principle of least surprise when > moving between distributions, but I don't have a position on way or the > other. > > At this time we can also reassess the hydrogen and hydrogen-data split. > If I was packaging Hydrogen from scratch I'm not sure that I would split > them... > > Finally, if we maintain the split, what is your position on .desktop and > appdata files? Should they go in bin:hydrogen-data, or in bin:hydrogen? OK - I think we are a bit too close to the next Debian release to be making things complicated. Maintaining a library complicates upgrades to new versions if transitions are required, and can be problematic if the the ABI is not stable. I don't know how stable the hydrogen library is. Why don't we just stick to how it was structured before it was removed? That way users of Hydrogen in making music (like me) can just use the application like they used to. We have to go through the NEW queue to get hydrogen into the next release, so making the ftp-master review as simple as possible (with a rock solid copyright file) is the least risky approach. I think the main reason for splitting stuff out into a *-data package is to split the architecture dependent files from the architecture independent files. When looking at the contents of the old hydrogen package, you could question some of the decisions between the -data and -doc packages. Maybe after the release we can think about helping developers of potential plugins, and moving files around between packages? That is unless the previous structural decisions contributed to any bugs! We can always backport new versions for users of Debian stable after the release if there is a demand. <snip> > > I've reopened this list of bugs. > >> Let me know when the new version is available on mentors. >> > Will do! I'd just want to take care of the major design decisions > first. > > Cheers, > Nicholas Cheers, Ross
Attachment:
signature.asc
Description: OpenPGP digital signature