Re: Separate lib and executable packages?
On Sat, Feb 08, 2020 at 02:42:11AM +0000, Scott Kitterman wrote:
>
>
> On February 7, 2020 3:59:46 PM UTC, Mattia Rizzolo <mattia@debian.org> wrote:
> >On Fri, Feb 07, 2020 at 11:36:00AM +0000, Gordon Ball wrote:
> >> I wonder if this split really makes sense; it feels like adding the
> >> overhead of an extra binary package to avoid not having a very small
> >> file in /usr/bin if you're only planning to use the library.
> >>
> >> Does it seem reasonable to drop the executable package and just make
> >it
> >> a Provides: of the library package? (and is there any potential
> >breakage
> >> here that I'm overlooking)
> >
> >
> >Maybe not for ipython3, since that's very much tied to
> >python3-ipython3.
> >
> >BUT, as a user (even forgetting I'm also a DD) I was hurt many times by
> >executables in python-foo but wanting to use python3-foo instead, or by
> >executables that moved from python-foo to python3-foo and I had to fix
> >my own deployments, and whatnot.
> >
> >We are not going to have a python4 anytime soon (hopefully never), but
> >I
> >think that keeping a separate binary package makes sense for almost all
> >cases I can think of packages shipping executables under /usr/bin/.
>
> Except: Every time we add a binary to Debian it impacts everyone. The packages file gets bigger and so updates get slower. Although there's no firm rule, the FTP Masters discourage addition of trivially small packages and so your package might be rejected.
>
Perhaps this is worth making an explicit recommendation for new packages
of this type, given that anything new _should_ be python3-only and we
hope for at least some time before another python major version becomes
an issue. "Packages which are primarily libraries but include an
executable should avoid multiple binary packages without good reason"? -
At least in the above linked style guide, since it's not normative
policy in any case.
For packages already split (eg, ipython3, python3-ipython), having
thought a bit more I suspect it's probably more trouble than it is worth
to drop a handful of binary packages - I'm wondering about eg, what
happens if the executable package is manually installed and the library
hence flagged as automatically installed; if the former than becomes a
Provides: of the latter, is it immediately a candidate for autoremoval?
> As an example, the dkimpy module that I maintain provides some scripts. Originally they were provided in python-dkim. Now they are provided in python3-dkim (and since python-dkim is gone in unstable/testing, there's no more chance of users being confused about which one to install to get the scripts).
>
> I recall a few questions by people that didn't know where to find the scripts. I could have had both packages provide it using update-alternatives, but the problem never seemed severe enough to be worth the work.
>
> While splitting things out as suggested makes sense from the perspective of a single package, it has negative implications for the distro as a whole. Maintainers: please be mindful of the cumulative impact of the addition many small packages that aren't strictly needed.
>
> Scott K
>
Reply to: