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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmPGnMoACgkQMRvlz3HQ eIP+SA/+I6Axbv2U6lEjxjEaIB4EOxrCtA8AnfYVKccPg1ZTag3BT4zuorDoVOAf nxfGayDpk+SxZpVjLZbmKOYlemLi1QAqFwyDQcyHUpjXAQdrKFtX48OlB/FNCxLN JYROfiqWsUCr2pa12hdEopGASp2mtE4O75a2zSxUGvLDDawIrRFFEimQA1XMB30A UbGSRkDdLNXiXovy3gi6H0k21Ndmyl0BhRAIBQwD7LEAQ7p0mcAkLBDM1wpKS9pw dfxkElUIjDvE+GhO2fSC3viGHDkqmgeJo4But7GAarkVtQRvuu3Qek2ODruzEi0m ZRefmiMBmeKBQLF1GE+0cfWeZvE0+Fd5CbQw/BmfsUtIejFY9wDyAvMpWf4xWuy7 ciFzwFhdvVLXU1rhQ7wFGHXDghNGXstngqxvXIWY1PnW/+cSJQdAIoueLXUJsxgt MNq1w/CTvIS0cuPnvwKkmOi8Tv4J0Pxc22BoqTbgoVOjzMkahz6d1i/lswpX6rj3 YmfJjpB5dNBjoY2qEkjHlbpn4sJGI22bQHLwgpXceaEh4xWGyE8X+e06FIoCAAn/ Cs0M3JifgwFDukfYRumJr4Y2bUT0ZT9fedfaVwAAt342lsKODmUZjjDzIcvr3cAV +b5BSz4IM9RevQh2R8StduTEYIwGP4P00NLd7Ix8NNew/m6eSZM=
=Ro4W
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)