Re: Separate lib and executable packages?
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. 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 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/. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Separate lib and executable packages?
Hi, it depends :). My two cents: If you are packaging application (PAPT team): * user is using it in CLI / Xorg * user don't need to know it's written in Python * Python modules are typically private, not usable by other applications/libraries -> one binary package: foo If you are packaging library (DPMT team): * your package is typically not usable by user directly * your package is typically dependency of other packages (Python applications/libraries) -> as many binary packages as "language branches" we have, e.g. python-foo, python3-foo, pypy-foo If you are packaging application with public library part (PAPT team): * both of above * user is using it in CLI / Xorg * BUT package have library part, which can be used in other Python applications/libraries -> as many binary packages as "language branches" we have, e.g. python-foo, python3-foo, pypy-foo + foo for application. "foo" package can contain more than entrypoints, but icons, menu items, ... -- Best regards Ondřej Nový
Separate lib and executable packages?
The library style guide [1] says under _Executables and library packages_: > Here are some recommendations. We do not have a standard (though maybe > we should) regarding whether a library with an associated executable should be split across `foo` and `python3-foo` or just bundled into `python3-foo`. Does anyone consider that there is now a standard either way? In eg, ipython this means shipping `ipython3` (containing a ~300 byte entrypoints script and a similarly sized man page) as a separate package to the implementation in `python3-ipython`. 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) Gordon [1]: https://wiki.debian.org/Python/LibraryStyleGuide
