Re: [Request for packaging] rinutils - a C library of headers used by Shlomi Fish's C projects (but may be of some limited general interest)
On Wed, 04 Mar 2020 at 21:45:49 +0200, Shachar Shemesh wrote:
> A Debian package needs to have a description that will be self
> explanatory to users, so they know what the package is for. "Some headers
> Shlomi Fish uses in some of his projects" does not meet that criteria.
If a few projects for which you're the upstream are the only consumers of
this library, I would suggest "vendoring" this header-only library into
the projects that need it (via git-subtree or git-submodule or multiple
orig tarballs or whatever other mechanism makes most sense to you),
similar to the way libglnx is used in assorted GNOME and GNOME-adjacent
projects (Flatpak and libostree are good examples). I know Debian policy
does not generally allow embedded code copies, but even Debian policy
does allow it when "the included package is explicitly intended to be
used in this way" (again, libglnx).
Debian's packaging workflow is generally based on the idea that a library
is general-purpose, API-stable and ABI-stable (obviously ABI stability
doesn't apply to a header-only library), and large enough to be treated
as a "product" in its own right. If separate libraries get too small,
numerous or API-unstable, our workflow doesn't really scale.
With a typical header-only library, I would expect to encounter somewhat
frequent API changes, unless the developer is careful to not do that
(meaning carrying around deprecated code for a significant time, perhaps
indefinitely). That seems unlikely to happen - and, to be honest, unlikely
to be justified effort - in a library that doesn't have third-party users.
I am also a big fan of using an established, maintained utility/runtime
library like GLib, SDL, NSPR, APR or Qt[*] rather that inventing your
own "make C a less horrible experience" runtime library, although I
can understand the appeal of not having external dependencies (and I
maintain at least one project, dbus, that did invent its own (not very
good) runtime library to avoid external dependencies). Having external
dependencies that are sufficiciently rare that your users probably don't
already have them seems like the worst of both worlds.
smcv
[*] No informed judgement on quality here; I mainly use GLib myself, and
haven't used NSPR or APR for a long time.
Reply to: