When I run debuild -us -uc on that, it generates:Yes, you usually need to use dh_install when having several subpackages.
debian/tmp/...
debian/tmp/usr/bin/<my console scripts>
debian/tmp/usr/lib/python3.11/dist-packages/foo
debian/tmp/usr/lib/python3.11/dist-packages/foo-1.0.0.dist-info
debian/tmp/usr/lib/python3.11/dist-packages/foo-1.0.0.dist-info/LICENCE
But then complains that the files aren't installed by anyone.
1) Is there some mechanism in dh_python that would automatically splitI don't think there is, and I don't think "usr/bin stuff should likely go
(respectively install) the files to the two packages, and I'm just
to dumb to use it?
Like that it knows, the Python package should likely go into the
python3-* Debian package, and usr/bin stuff should likely go in the
other?
2) I then tried with such package.install files like those:You can check the search logic in dh_install(1).
foo-util.install:
usr/bin
python3-foo.install:
usr/lib
a) Why does it work to use just usr/... and not debian/tmp/usr/... ?
Actually, both seems to work, which confuses me even more ^^
b) What - if any - is the proper way here? Like I did, with oneYes, because the files are already installed into correct destinations.
argument?
Or should one use the two arguments per line version?No.
Or perhaps (for the 2nd file) rather usr/lib/python* ?
Or rather the debian/tmp/usr/ path versions?
Or using something completely different than dh_install?
3) In debian/tmp, the subdir was /python3.11/ but in the final .debYes, it's expected.
file it's actually /python3/ (as I think it should be).
Is it expected, that first it's /python3.11/ or am I doing anything
wrong?
4) Are there way to have the Dependencies in control even moreNo, as there is no data to use here.
autodetected?
a) That foo-util's dependency on python3-foo is somehow auto-filled
by dh_python?
b) Or the Build-Deps? I mean dh_python should at least be able toYou cannot autodetect build dependencies at the build time. That would be
find out about python3-setuptools, python3-setuptools-scm from my
pyproject.toml, shouldn't it?
5) Not really 100% Debian related, but in the Python sdist,... shouldNo, and the upstream source shouldn't contain debian/ anyway, as the life cycles of packaging and upstream sources should be separate even if the
that contain the debian/*?
2) I then tried with such package.install files like those:
foo-util.install:
usr/bin
python3-foo.install:
usr/lib
a) Why does it work to use just usr/... and not debian/tmp/usr/... ?
Actually, both seems to work, which confuses me even more ^^
b) What - if any - is the proper way here? Like I did, with one
argument?
Or should one use the two arguments per line version?
Or perhaps (for the 2nd file) rather usr/lib/python* ?
3) In debian/tmp, the subdir was /python3.11/ but in the final .deb
file it's actually /python3/ (as I think it should be).
Is it expected, that first it's /python3.11/ or am I doing anything
wrong?
4) Are there way to have the Dependencies in control even more
autodetected?
a) That foo-util's dependency on python3-foo is somehow auto-filled
by dh_python?
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.
debian/control (all boring fields removed):
Source: foo
1) Is there some mechanism in dh_python that would automatically split
(respectively install) the files to the two packages, and I'm just
to dumb to use it?
debian/control (all boring fields removed):
Source: foo
Package: python3-foo
Package: foo-util
5) Not really 100% Debian related, but in the Python sdist,... shouldNo, and the upstream source shouldn't contain debian/ anyway, as the life cycles of packaging and upstream sources should be separate even if the person doing both is the same.
that contain the debian/*?
Not necessarily, some people make non-native packages and store debian/ in5) Not really 100% Debian related, but in the Python sdist,... shouldNo, and the upstream source shouldn't contain debian/ anyway, as the life cycles of packaging and upstream sources should be separate even if the person doing both is the same.
that contain the debian/*?
This would then be a "native" package, and it's not recommended to use this package format in most cases:
On Wed, 12 Jul 2023 at 11:19:07 +0200, Andrey Rakhmatullin wrote:Oh yeah, I just tried to say that packaging them separately is not the
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.
If nothing else, making executables part of the interface of theThere is a popular concern about having binary packages that consist of a
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.
If the Python library is considered to be a private implementation detailYup.
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).
What do you mean by the terms "simple Python package" and "two packages"? These terms do not exists in Python context.These are Debian terms.
Python do differentiate betweenIt's the Debian source package as the context is debian/control. Or what
"Distribution Package" (the name you would find e.g. on PyPI) and "Import Packages" (the name you use with your "import" statement). And there is also a difference with "Debian Package" (a deb-file). Of course all three type of packages can be the same but don't have to.
Am 12.07.2023 02:21 schrieb Christoph Anton Mitterer:
debian/control (all boring fields removed):
Source: foo
I assume that "foo" is the "Distribution Package" ?
Package: python3-foo1) Is there some mechanism in dh_python that would automatically split
(respectively install) the files to the two packages, and I'm just
to dumb to use it?
I don't understand why there are two packages? Why two? I can not find that in your setup.
It's definitely possible and I would expect any good guide to mentiondebian/control (all boring fields removed):
Source: foo
Package: python3-foo
Package: foo-util
You build two Debian packages (deb-files) out of one source tarball? Interesting to know that this is possible.
On Wed, Jul 12, 2023 at 11:05:57AM +0000, c.buhtz@posteo.jp wrote:
You build two Debian packages (deb-files) out of one source tarball?It's definitely possible and I would expect any good guide to mention
Interesting to know that this is possible.
this.
If you want to learn about Debian source packages that build severalYou build two Debian packages (deb-files) out of one source tarball? Interesting to know that this is possible.It's definitely possible and I would expect any good guide to mention
this.
I really need to see the full repo to better understand whats going on here.
One pyproject.toml indicates one and only "Python Distribution Package". I can not imagine why someone would split it up into two "Debian packages"?This is answered in the original email. One package for the module and
Isn't it easier (from Debian Package Maintainers view) to have one "Python Distribution Package" per "Debian package". So when I want two Debian packages I would create to Python Distro packages in my upstream repo.No, and it makes no sense to do that.
I don't think there is, and 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.
a) Why does it work to use just usr/... and notdebian/tmp/usr/... ?
Actually, both seems to work, which confuses me even more ^^You can check the search logic in dh_install(1).
b) What - if any - is the proper way here? Like I did, with oneYes, because the files are already installed into correct
argument?
destinations.
Or should one use the two arguments per line version?No.
Or perhaps (for the 2nd file) rather usr/lib/python* ?
Or rather the debian/tmp/usr/ path versions?
Or using something completely different than dh_install?
3) In debian/tmp, the subdir was /python3.11/ but in the final .debanything
file it's actually /python3/ (as I think it should be).
Is it expected, that first it's /python3.11/ or am I doing
wrong?Yes, it's expected.
You cannot autodetect build dependencies at the build time. That
would be
too late.
No, and the upstream source shouldn't contain debian/ anyway, as the
life
cycles of packaging and upstream sources should be separate even if
the
person doing both is the same.
a) Why does it work to use just usr/... and notdebian/tmp/usr/... ?
Actually, both seems to work, which confuses me even more ^^
From debhelper compatibility level 7 on, dh_install will fall
back to
looking in debian/tmp for files, if it does not find them in
the
current directory (or wherever you've told it to look using
--sourcedir).
— dh_install(1)
So what dh_install -pfoo-util does for the usr/bin line is:
- is there a ./usr/bin? - no
Writing it out the long way is only necessary if
you're
doing multiple builds (like dbus, which builds and installs the same
source code with different options into debian/tmp and debian/tmp-
udeb)
Or perhaps (for the 2nd file) rather usr/lib/python* ?
IMO it's often good to be relatively specific in .install files, so
that
if your upstream makes an incompatible change, attempting to build an
updated package without acknowledging the change will FTBFS and alert
you
that something unusual is happening.
So I would personally be inclined
to use something like
usr/lib/python3*/dist-packages/foo
usr/lib/python3*/dist-packages/Foo-*.egg-info
on the basis that if those no longer match, then upstream has made a significant change that will affect compatibility for third-party
code,
in which case I want to know about it (and perhaps do an experimental
upload and check that dependent packages are ready for it before
going
to unstable).
because within the same
source package it's common to make use of internal interfaces that
are
not considered to be public API - so you probably want to override it
so it will depend on python3-foo (= ${binary:Version}) anyway.
Do you have a link to your repository?
What do you mean by the terms "simple Python package" and "two
packages"?
debian/control (all boring fields removed):
Source: foo
I assume that "foo" is the "Distribution Package" ?
I don't understand why there are two packages? Why two? I can not
find that in your setup.
You build two Debian packages (deb-files) out of one source tarball? Interesting to know that this is possible.
Doesn't this answer "Why does it work to use just usr/... and not debian/tmp/usr/... ?"?a) Why does it work to use just usr/... and notdebian/tmp/usr/... ?
Actually, both seems to work, which confuses me even more ^^You can check the search logic in dh_install(1).
Well I have read that but it merely says it uses the current dir (which
I didn't know how it's determined) and falls back to debian/tmp (with
the right debhelper compat lvl)
I mean their locations relative to debian/tmp are correct and the only remaining thing is moving them, keeping their relative paths, intob) What - if any - is the proper way here? Like I did, with oneYes, because the files are already installed into correct
argument?
destinations.
How do you mean that? Cause when I look at the generated files, they're actually below debian/tmp/usr/bin and not in debian/usr/bin?
I don't think it's bad practice, it will work just as well.Or should one use the two arguments per line version?No.
Or perhaps (for the 2nd file) rather usr/lib/python* ?
Or rather the debian/tmp/usr/ path versions?
Or using something completely different than dh_install?
Just out of curiosity, why is the "rather usr/lib/python*" thingy
considered bad practise?
You can do anything you want for packages not aimed for inclusion intoNo, and the upstream source shouldn't contain debian/ anyway, as the
life
cycles of packaging and upstream sources should be separate even if
the
person doing both is the same.
Well, yes... but so far this is only Debian packaging for private use.
Not sure if the project is of enough general use to submit to Debian.
How does one know (I guess it must be written somewhere and I just
missed it - or was to lazy to read the relevant section O:-) ) which
one the "current directory" is in which stage of the build?
Or is it simply always ./debian/?
I would personally be inclined
to use something like
usr/lib/python3*/dist-packages/foo
usr/lib/python3*/dist-packages/Foo-*.egg-info
This I don't however understand fully. I thought at least the dist-
packages/ intermediate dir would come from pybuild?
Or is your aim rather at the foo and Foo-*.egg-info? Well for those I
had hoped pybuild would do all possibly necessary checks.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 116:23:44 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,800 |