[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: how to properly split up into python3-foo and foo-util package?



On Wed, Jul 12, 2023 at 11:16:28AM +0100, Simon McVittie wrote:
> On Wed, 12 Jul 2023 at 11:19:07 +0200, Andrey Rakhmatullin wrote:
> > I don't think "usr/bin stuff should likely go
> > in the other". Many Python module packages ship executables, especially
> > now that you no longer have Python 2 subpackages.
> 
> I would personally say that if the executables are significant, and
> particularly if we expect that users will use them without knowing or
> caring whether they are implemented in Python, then they should be in
> a package with a name and Section that make it look like an executable
> program and not a Python library: if nothing else, that will make them
> a lot more discoverable. So I think Christoph is probably correct to be
> thinking about shipping them as foo-util or similar.
Oh yeah, I just tried to say that packaging them separately is not the
only option and probably not even the main option.

> If nothing else, making executables part of the interface of the
> python3-foo package is going to come back to bite us when Python 4 happens
> (hopefully not soon, but if there have been 3 major versions then there
> will probably be a 4th eventually).
> 
> If the Python library is considered to be a public API, then it should
> be in a python3-foo library. src:binwalk and src:tap.py are examples
> of separating out executable + library like this.
There is a popular concern about having binary packages that consist of a
1 kB file + changelog + copyright. It also somewhat complicates packaging,
unfortunately.

> If the Python library is considered to be a private implementation detail
> of the executables, then it doesn't need to be packaged separately
> (for example bmap-tools, dput, meson and offlineimap all contain
> private Python libraries that are not a stable API), and ideally it
> would be in a location that is not on the default import search path,
> like /usr/share/foo or /usr/lib/foo (dput and offlineimap do this,
> although bmap-tools and meson don't).
Yup.


Reply to: