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)
Hi Simon, Shachar, and all!
On Wed, 4 Mar 2020 21:00:55 +0000
Simon McVittie <smcv@debian.org> wrote:
> 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).
>
One reason I created rinutils is because I had some duplicate header files
across my projects. I was able to get it packaged successfully for mageia and
fedora, but the debian maintainer of the freecell-solver package told me he'd
prefer not to package it himself, so I should find someone to package it or
make it only an optional build dep.
In version 5.20.1 I embedded a copy of rinutils 0.2.0 inside the tarball and
used some cmake glue to use it if it cannot find a system installation of
rinutils:
https://github.com/shlomif/fc-solve/blob/master/fc-solve/source/NEWS.asciidoc
While the actual change was done relatively quickly, getting the release script
(see
https://github.com/shlomif/fc-solve/blob/master/fc-solve/scripts/mint-new-release.bash
) to run to success took several hours, which could have been saved if a debian
package of rinutils would have been made.
> 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.
>
ok.
> 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.
>
Well, I think most of the headers in rinutils have no equivalent (or at least
only have a less performant one) in glib/etc. and are rather specialised.
libfreecell-solver also has a compile-time option to use some "3rd party" open
source https://en.wikipedia.org/wiki/Associative_array implementations including
glib's hash and glib's tree and judytree and they all are noticably less
performant than its own internal hash implementation (which isn't part of
rinutils).
I don't rule out using libraries in all cases, though.
Anyway, I extracted rinutils into its own package to comply with fedora's
policy, and it was eventually packaged for it:
https://src.fedoraproject.org/rpms/rinutils
> 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: