Re: Separate lib and executable packages?
On Saturday, February 8, 2020 2:50:54 PM EST Gordon Ball wrote: > On Sat, Feb 08, 2020 at 02:42:11AM +, Scott Kitterman wrote: > > On February 7, 2020 3:59:46 PM UTC, Mattia Rizzolo wrote: > > >On Fri, Feb 07, 2020 at 11:36:00AM +, 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 signature.asc Description: This is a digitally signed message part.
Re: Separate lib and executable packages?
Hi, so 8. 2. 2020 v 20:51 odesílatel Gordon Ball napsal: > Perhaps this is worth making an explicit recommendation for new packages > of this type, given that anything new _should_ be python3-only and we > and what about pypy- prefix? -- Best regards Ondřej Nový
Re: Separate lib and executable packages?
On Sat, Feb 08, 2020 at 02:42:11AM +, Scott Kitterman wrote: > > > On February 7, 2020 3:59:46 PM UTC, Mattia Rizzolo wrote: > >On Fri, Feb 07, 2020 at 11:36:00AM +, 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 >
Re: Separate lib and executable packages?
On February 8, 2020 12:38:54 PM UTC, Ondrej Novy wrote: >Hi, > >so 8. 2. 2020 v 4:11 odesílatel Scott Kitterman >napsal: > >> 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. >> > >so let's fix infrastructure? That's what everyone always suggests, but no one ever does. AFAIK, there's no agreed design for secure package updates that doesn't require a local copy of the packages file. If Debian could quit worrying about adding lots of little binaries, it would help in many areas. Scott K
Re: Separate lib and executable packages?
Hi, so 8. 2. 2020 v 4:11 odesílatel Scott Kitterman napsal: > 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. > so let's fix infrastructure? -- Best regards Ondřej Nový
