Re: Python distributions with multiple packages

[Stefano Rivera]

Hi c.buhtz (2022.08.26_11:10:03_+)
> today I found out that it is possible to create a Python "Distribution
> Package" [1] (e.g. a whl-file) that contain more then one "Importable
> Packages" [2].
> 
> Are you aware of any packages in Debian that are related to upstream
> projects using that "technic"?

This has always been somewhat frowned upon, but it's not that uncommon.
Offhand, I can think of python3-configobj, which upstream is in the
process of tidying up.

> And if so how do you (as debian distro maintainers) handle that? Do you
> create one deb-file for "mydistropackage" (e.g.
> "python3-mydistropackage.deb") or do you separate into "python3-mya.deb" and
> "python3-myb.deb"?

Sometimes we do the one, sometimes the other. It depends.

A famous example is pkg_resources, which is shipped in setuptools,
upstream. We packaged it as a separate module, because it's a runtime
dependency of many packages, but they don't need the whole of setuptools
at runtime.

When we split packages like this, it breaks our automatic dependency
generation tools.  They understand upstream's dependency declarations,
so we have to manually add dependencies to packages that depend on split
libraries.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Proposed MBF: packages still using nose

[Jakub Wilk]

  anorack


Fixed upstream in 0.2.8.


  mwic


Fixed upstream in 0.7.9.


  python-djvulibre


Fixed upstream in 0.8.7.
This one should probably be removed, though: there are no rev-deps, it's 
orphaned in Debian, and it's likely to be orphaned upstream soon too.


--
Jakub Wilk

Python distributions with multiple packages

[c . buhtz]

Hello,

today I found out that it is possible to create a Python "Distribution 
Package" [1] (e.g. a whl-file) that contain more then one "Importable 
Packages" [2].


So you can do "pip3 install mydistropackage" and after that you can do 
"import mya" and "import myb".


Are you aware of any packages in Debian that are related to upstream 
projects using that "technic"?


And if so how do you (as debian distro maintainers) handle that? Do you 
create one deb-file for "mydistropackage" (e.g. 
"python3-mydistropackage.deb") or do you separate into "python3-mya.deb" 
and "python3-myb.deb"?


Kind
Christian Buhtz

[1] -- 

[2] -- 

Re: New package for tpm2-pytss

[Claudius Heine]

Hi,

On 2022-08-25 17:36, Carsten Schoenert wrote:

Hi,

Am 25.08.22 um 09:25 schrieb Claudius Heine:


I am not possessive about this package and would like to share
maintainer-ship if possible. For me this is contract work, I am not
doing this for myself, but for a customer, which will continue to use
this and packages around it for rolling out Linux-based Desktop systems
for their employees. So I suspect that this will be used and maintained
in any case, even if not my me personally.


well, if packaging work is covered any payed by the employee or 
costumers than this is great as it also shows it's possible to earn 
money with FOSS.


I just wanted to stress out that it's sometimes better to not start 
packaging work if it's already recognizable that were will no time 
afterwards to do the maintenance work, which is mostly more work than 
the initial packaging. At some point almost every software will get some 
security update which needs to get incorporated into the package and the 
archive. As you work for DENX I'm quite sure what I mean. :-)


I CCed some folks that would possible be involved in keeping this and 
possible other packages maintained as well...


So I guess we should then just join the python-team next right?

- I want to help maintain python packages
- My salsa account is: cmhe
- And I read and agree to the Debian Python Team Policy [1]


Debian already contains the tpm2-pkcs11 package, which in its newest
version (1.8.0) (see #1011376 [1]) will require tpm2-pytss (which this
is about). So I guess sooner or later (if tpm2-pkcs11 is still
maintained), someone will need to create tpm2-pytss as well.

tpm2-pkcs11 1.8.0 is required to fix bugs when used with openssl 3, that
are present in older versions (1.7.0).

My goal here mainly was to help and speed up the upgrade of tpm2-pkcs11
to 1.8.0 by supplying the tpm2-pytss package. Also of course avoiding
low-quality and duplicate work by providing the packages to upstream 
Debian.


...


Yes, sure. I already started doing that as soon as my salsa account was
approved:

https://salsa.debian.org/cmhe/tpm2-pytss

That should work already, but currently I am just adding salsa-ci
support, and possible fixing some metadata issues.


I've take a look and opened up a MR to address some small things I've 
noted. Your work looks good so far.


https://salsa.debian.org/cmhe/tpm2-pytss/-/merge_requests/2

Feel free to cherry-pick or merge in the modifications.


All your changes looked great, I learned a lot from them and integrated 
them all.


I haven't looked yet into potential copyright things, if some other 
member would have time to have also a look at this that would be great.

That would be welcomed!

regards,
Claudius

[1] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst