On Saturday, February 8, 2020 2:50:54 PM EST Gordon Ball wrote: > 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. Sounds reasonable to me. It's a wiki, so I'd say go for it. > 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? Yes. Removing the existing cases where it might not really be needed can be problematic. I think it generally makes sense to leave them be. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.