Hey.


Maybe someone can help me with the following:


I have a little Python project that uses setuptools or packaging. Only
with pyproject.toml, no setup.py or so.

pyproject.toml specifies the build-dependencies like so:
[build-system]
requires = ["setuptools>=61.0.0", "setuptools_scm[toml]>=6.2.0"]
build-backend = "setuptools.build_meta"

There are no other external dependencies (like modules other than that
from the standard library).

The project contains a simple Python package, and pyproject.toml
specifies a number of console scripts (which it then auto-generates)
like so:
[project.scripts]
foo-util = "foo.__main__:main"
foo-util-bar = "foo.__main__:main-bar"

Building that works fine.


Now I've added Debian packaging using dh_python.

debian/rules:
$ cat rules
#!/usr/bin/make -f

%:
dh $@ --with python3 --buildsystem=pybuild

debian/control (all boring fields removed):
Source: foo
Build-Depends: debhelper-compat (= 13), dh-python, python3-all, pybuild-plugin-pyproject, python3-setuptools, python3-setuptools-scm

Package: python3-foo
Architecture: all
Depends: ${python3:Depends}, ${misc:Depends}

Package: foo-util
Architecture: all
Depends: ${python3:Depends}, ${misc:Depends}, python3-foo

When I run debuild -us -uc on that, it generates:
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.


Now I'd have a number of questions ;-)


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?
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?

Or is it necessary (and the proper way) to have package.install
files for doing that?


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* ?
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 .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?
b) Or the Build-Deps? I mean dh_python should at least be able to
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,... should
that contain the debian/*?
I found:
https://docs.python.org/3/distutils/sourcedist.html#specifying-the-files-to-distribute
but couldn't find any info on what best practises are, whether
packaging files for other packaging systems should be included or
not.


6) Last but not least, the:
debian/tmp/usr/lib/python3.11/dist-packages/foo-1.0.0.dist-info/LICENCE
It's basically just what's already in /u/s/d/python3-foo/copyright
so just eats up space.
Is it recommended to explicitly strip it somehow (how? ^^) from the
Debian package?



Thanks a lot folks :-)

Cheers,
Chris.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 12, 2023 at 02:21:48AM +0200, Christoph Anton Mitterer wrote: <irrelevant details skipped>

When I run debuild -us -uc on that, it generates:
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.

Yes, you usually need to use dh_install when having several subpackages.
This is not Python-specific.

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?
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?

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.

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 ^^

You can check the search logic in dh_install(1).

b) What - if any - is the proper way here? Like I did, with one
argument?

Yes, because the files are already installed into correct destinations.

Or should one use the two arguments per line version?
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?

No.

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?

Yes, it's expected.

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?

No, as there is no data to use here.

b) Or the Build-Deps? I mean dh_python should at least be able to
find out about python3-setuptools, python3-setuptools-scm from my
pyproject.toml, shouldn't it?

You cannot autodetect build dependencies at the build time. That would be
too late.

5) Not really 100% Debian related, but in the Python sdist,... should
that contain the debian/*?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Jul 2023 at 02:21:48 +0200, Christoph Anton Mitterer wrote:

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 ^^

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
- is there a ./debian/tmp/usr/bin? - yes, so package that

I think the short form with just usr/... is the more obvious one in simple cases like this. 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 if you have to disambiguate because your source code contains a
./usr directory.

But if you put a greater value on "explicit is better than implicit"
than I do, then you might prefer to prefix everything with debian/tmp/.

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?

If the upstream package installs files into their correct places, then
one argument per line is fine, and provides "don't repeat yourself".

More than one argument per line is for when you want to change upstream's installation location for whatever reason, for example:

usr/bin/this-is-a-game usr/games

or when you are taking a file from the source tree that is not installed
by the upstream build system, and installing it directly:

contrib/utils/some-extra-utility usr/bin

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).

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?

I think this is expected, dh_python3 moves it around automatically.

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?

Even if it was auto-detected, dependencies within a single source
package should usually be relatively strict, 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.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

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).

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Christoph,

I'm sure I can not help you but I'm asking because I want to learn.

Do you have a link to your repository?

What do you mean by the terms "simple Python package" and "two
packages"? These terms do not exists in Python context. Python do
differentiate between "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" ?

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?

I don't understand why there are two packages? Why two? I can not find
that in your setup.

Am 12.07.2023 02:21 schrieb Christoph Anton Mitterer:

debian/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.

It would be great if you could upload your "foo" repository somewhere
when it works as an example.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

5) Not really 100% Debian related, but in the Python sdist,... should
that contain the debian/*?

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.

This would then be a "native" package, and it's not recommended to use
this package format in most cases: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#native

While it can happen that a developer maintains the Debian packages for
their own software, they also have to consider other dpkg-based
distributions, such as Ubuntu. Maintaining the Debian changelog for both
in the same upstream repository isn't a lot of fun.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 12, 2023 at 12:16:51PM +0200, Gregor Riepl wrote:

5) Not really 100% Debian related, but in the Python sdist,... should
that contain the debian/*?

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.

This would then be a "native" package, and it's not recommended to use this package format in most cases:

Not necessarily, some people make non-native packages and store debian/ in
the VCS. It's not a good idea, though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 12, 2023 at 11:05:57AM +0000, c.buhtz@posteo.jp wrote:

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 between
"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" ?

It's the Debian source package as the context is debian/control. Or what
do you mean?

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?

I don't understand why there are two packages? Why two? I can not find that in your setup.

Package: python3-foo
Package: foo-util

debian/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.

It's definitely possible and I would expect any good guide to mention
this.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 12.07.2023 13:25 schrieb Andrey Rakhmatullin:

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?
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"?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 12, 2023 at 11:56:05AM +0000, c.buhtz@posteo.jp wrote:

You 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.

If you want to learn about Debian source packages that build several
binary packages you can look at any such package in the archive.

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
another one for the executable.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey.

Sorry for the delay. I'm not subscribed to the list and forgot
mentioning to keep me on CC. ^^


On Wed, 12 Jul 2023 11:19:07 +0200, Andrey Rakhmatullin wrote:

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.

Well I admit that it's probably a bit overkill in my case, but I mainly
did it for the reasons laid out by Simon (btw: thanks for your answers
as well).

I always found things like exiftool, which "hides" behind what most
average users will consider to be a library package (libimage-exiftool-
perl), rather unfortunate.
It may even disturb packaging, considering e.g. apt's auto-installed
flag.

Sure that's now Perl, but similar examples exist for Python.
So I would have added that extra package mostly for "convenience" and
perhaps also for non-library documentation (should I ever come around
to write one ^^)

a) Why does it work to use just usr/... and not

debian/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)

b) What - if any - is the proper way here? Like I did, with one
argument?

Yes, because the files are already installed into correct
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?

Or should one use the two arguments per line version?
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?

No.

Just out of curiosity, why is the "rather usr/lib/python*" thingy
considered bad practise?
I kinda thought that anything not installed there, except perhaps for documentation, would first not be ought to be part of the python3-xxx package... and could rather be just some unwanted build artefact.
So I kinda liked the idea that one would need to include such things specifically.

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?

Yes, it's expected.

Thanks :-)

You cannot autodetect build dependencies at the build time. That
would be
too late.

Haha... so obvious... I shouldn't write such mails so late in the
night.

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.

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.
Should I ever do that, then I guess I'd simply rewrite the whole git
history and split everything in debian/* out into a separate branch.



Thanks for your answers :-)

Best wishes,
Chris.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2023-07-12 at 02:21 +0200, Simon McVittie:

a) Why does it work to use just usr/... and not

debian/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

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/?

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)

I guess I'll save such more complex package setups for a later occasion
;-)

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.

That was basically also my idea, which is why - at least until Andrey’s
reply - I was going by
usr/lib/python*
(fearfully anticipating a Python4 ;-P).

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).

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.

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.

Good point... and yes... I should probably tie these together.


Thanks as well, really helped (just as Andrey’s answer)

Best wishes,
Chris.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12 Jul 2023 11:05:57 +0000, c.buhtz@posteo.jp:

Do you have a link to your repository?

I'm afraid it's not (yet) publicly available. The whole thing started
out as a poorly written set of shell scripts 10 years ago and I finally
got my act together to re-implement it in Python.

It still lacks a reasonable test suite, documentation, etc. pp. ... and
I wouldn't wan to "release" it in that (not even) half finished status.

What do you mean by the terms "simple Python package" and "two
packages"?

Sorry for the confusion... as Andrey already explained, the "two
packages" referred to Debian packages - not Python package (of which my
example would indeed have only one).

debian/control (all boring fields removed):
Source: foo

I assume that "foo" is the "Distribution Package" ?

Indeed.

I don't understand why there are two packages? Why two? I can not
find that in your setup.

Again, this meant Debian packages... as already said by Andrey, it
follows from the conrol file,... and Simon gave good reasons why this
would make sense.

You build two Debian packages (deb-files) out of one source tarball? Interesting to know that this is possible.

That's absolutely common... you should rather look at "monsters" like
the gcc Debian source packages, which build a few gazillion (it seems
sometimes ;-) ) binary packages out of one source package :-D


Cheers,
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 17, 2023 at 10:53:58PM +0200, Christoph Anton Mitterer wrote:

a) Why does it work to use just usr/... and not

debian/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)

Doesn't this answer "Why does it work to use just usr/... and not debian/tmp/usr/... ?"?
And the current dir when building a package is the source root.

b) What - if any - is the proper way here? Like I did, with one
argument?

Yes, because the files are already installed into correct
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 mean their locations relative to debian/tmp are correct and the only remaining thing is moving them, keeping their relative paths, into
respective debian/pkgname dirs, which is precisely what the second mode of dh_install(1) is for.
And debian/usr/bin is a wrong path that is not used at any build step.

Or should one use the two arguments per line version?
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?

No.

Just out of curiosity, why is the "rather usr/lib/python*" thingy
considered bad practise?

I don't think it's bad practice, it will work just as well.

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.

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.

You can do anything you want for packages not aimed for inclusion into
Debian. This applies even to packaging.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 17 Jul 2023 at 23:16:03 +0200, Christoph Anton Mitterer wrote:

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/?

All the targets in debian/rules are invoked from the top-level source directory, so relative paths like ./debian/rules will exist.

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.

I meant the part inside dist-packages. If version 1.0 had the paths I
quoted above, but my upstream changes the package so that in version 1.5,
it now installs:

usr/lib/python3*/dist-packages/foo
usr/lib/python3*/dist-packages/bar
usr/lib/python3*/dist-packages/Foobar-*.egg-info

then those are changes which affect compatibility with other software that depends on this library, and I will need to react to them appropriately in
the packaging (and I can update the .install file at the same time).

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)