[Pkg-shadow-devel] Bug#1032393: Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Guillem Jover]

On Sun, 2023-03-12 at 21:53:14 +0100, Alejandro Colomar wrote:
> On 3/12/23 20:22, Bálint Réczey wrote:
> > Alejandro Colomar ezt írta (időpont: 2023. márc. 12., V, 16:52):
> >> On 3/12/23 16:38, Bálint Réczey wrote:
> >>>> 142 lines of a function definition are not something I'd consider easy to
> >>>> maintain.  Is it a big deal to add another dependency?  I'd say it's a
> >>>> bigger deal to copy verbatim so many lines of code, and sync them from
> >>>> time to time from libbsd (or OpenBSD) just to bring in any bugfixes they
> >>>> apply.  That's exactly the purpose of libbsd, so I think relying on them
> >>>> should be fine.
> >>>
> >>> The function does not change often. It changed two times in the last 13 years:
> >>> https://gitlab.freedesktop.org/libbsd/libbsd/-/commits/main/src/readpassphrase.c
> >>>
> >>> I'd be happy to add a GitHub Action job or an autopkgtest in Debian to
> >>> check if shadow's local copy needs an update.
> >>>
> >>> Depending on libbsd would pull the library into every single docker
> >>> container image increasing their size and would make libbsd part of
> >>> the pseudo-essential set, thus I prefer not depending on it for a few
> >>> lines of code.
> >>
> >> libbsd0 is only ~ 200 kB (installed size).  That should be
> >> insignificant compared to a Debian docker image, or even to the
> >> shadow packages.
> >>
> >> libsubid4 is ~ 300 kB
> >> uidmap is    ~ 300 kB
> >> login is     ~ 2.6 MB
> >> passwd is    ~ 2.8 kB
> >>
> >> And the unstable-slim Debian Docker image is around 28 MB
> >> (compressed size).

The sid-slim image I've got here uses around 82 MiB installed.

> >> Moreover, having this libbsd part of the pseudo-essential set would
> >> allow many other packages to rely on it, thus deduplicating the
> >> copies that some projects currently do to avoid depending on it,
> >> so the total distribution size could even shrink in the long term.
> > 
> > Developers of Debian are expected to be very conservative regarding
> > expanding the (pseudo-) essential set:
> > https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages
> > 
> > I value keeping the essential set minimal above providing one more
> > shared library for potential reverse dependencies, too.
> > I'd like to hear more people's opinion from the shadow project and if
> > the project insists on adding the libbsd dependency I will bring the
> > topic to debian-devel following the spirit of the Debian Policy
> > offering to either carry a copy of readpassphrase.c as a patch in the
> > Debian package or adding the libbsd dependency.

> I've CCd Guillem to know his opinion too.

Thanks. Because there's been no users before, I've never considered
such addition. And for packages where I'm upstream in the essential
set, I've always preferred to use portable interfaces to depending on
libbsd myself.

But then, the main reason to create libbsd, was precisely to try to
reduce code duplication and have a single place to store and maintain
these interfaces. I strongly believe that we should in general try to
reduce embedded code and vendoring, which are a technical detriment
to the distribution (and the software ecosystem in general).

> IMO, the functionallity provided by libbsd is essential; so much that
> I think glibc should pick it.  However, now that libbsd has it, it's
> not so important to add it to glibc, but then libbsd has to have a
> status similar to libc.

It is already picking up parts of it. But there are parts in it that I
don't see glibc adopting, so I'm afraid there will always be something
that keeps libbsd alive.

> We've fixed many bugs in shadow with the help of libbsd, and I think
> many projects would benefit from having it available.
> 
> But of course, that needs agreement of libbsd's maintainer (Guillem),
> and the debian-devel team.  Let's see what they and the shadow
> maintainers think.

dpkg started depending on libmd recently (which libbsd depends on),
also because I didn't feel like keeping embedding yet another MD5
implementation, and to make it possible to start using SHA variants in
the future in the code base.

On the cons, I'm perhaps missing something, but I don't see any other
obvious candidates in the essential-set that I could see starting to
use libbsd, but OTOH we have other libraries depended on by only a
single source package so this does not seem like a huge issue.

On the pros, libbsd is rather small in size; adding a shared library
to the essential-set should be a non-issue, as that's an implementation
detail, and does not increase the exposed interface for eternity, as
once a package there stops using the shared library it simply gets
evicted from the essential-set. If the shadow upstream and Debian
maintainers do not see an issue with depending on libbsd, then
personally I have no issues with it being added to the essential-set
if debian-devel sees no issue with it.

Also, another option in the future could be to remove login from the
essential-set (and passwd is not part of the essential-set anyway), as
covered in <https://wiki.debian.org/Proposals/EssentialOnDiet>, which
could make this even less of a potential issue.

Thanks,
Guillem