Hi, On Sun, Jan 15, 2023 at 01:21:59PM +0000, Matthew Fennell wrote: > I'm looking into whether it is feasible to package EnTT [1], a header-only C++ > library with breaking API changes every few releases / months. As I use it in a private toy-project I can certify that it is breaking API (and ABI) all the time, if header-only wasn't a strong hint already… I doubt this will change as it is clearly not a goal, so I am just skipping over the usual suggestion of talk to upstream first. > 2) Create a virtual package libentt-dev which depends on the latest binary > package: > > Package: libentt-dev > Depends: libentt3.12-dev Borderline nitpick, but this would be a "metapackage" and not a virtual package. A "virtual package" is what conceptionally happens if you have a "Provides: foobar (= 42)" assuming there exists no real package foobar. Real-world examples would be mail-transport-agent or awk. > 3) Have each new binary package version Conflict with all previous versions, to > prevent users from trying to install the same headers from multiple versions? > > Package: libentt3.12-dev > Conflicts: libentt3.11-dev, libentt3.10-dev, (...) You are borderline violating policy with this (packages in main are not supposed to conflict with each other except for good reason), but more importantly, what is it that you want to gain by doing this? (yes, this is a trick question) > Additionally, would I only then remove old versions from the archive when there > are no more reverse-dependencies left for that version of the package in stable > and testing? While your steps would certainly work and are what is basically happening for the big guys like python, gcc, clang and co (except that those are at least co-installable) this tends to be a giant pain in the buttocks (excuse my french) for everyone involved and you would involve a couple of people from ftpmasters (accepting new packages) to release team (for frequent transitions) and everyone in between for a rather small special-interest package. So, your steps might be sound, but in practice it sounds to me like you are throwing the baby out with the bathwater (see trick question). Dear ImGui (src:imgui) is in pretty much the same boat, somewhat likely to be another dependency of tools/games depending on EnTT, and is handled in a (seemingly, I haven't looked closely and I don't maintain it, not even using the package yet, so I could be all wrong) simpler way: It is just packaged as src:imgui and the binary libimgui-dev (containing the headers and a static library). The individual versions aren't co-installable obviously, but that was what you wanted to prevent with 3) anyhow in your scheme. Many automatic tools will be of no help as header-only means there is no (obvious) record of which version of EnTT a binary package was build against (yeah, buildinfo, but that isn't commonly used/available in an obvious way so far), so it is somewhat in your responsibility to ensure your reverse dependencies are updated rather than e.g. just waiting for FTBFS to come in from archive-wide rebuild efforts. I would suggest talking to maintainers of similar packages, they can probably give you more practical advice in this matter. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature