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

    From Christoph Anton Mitterer@21:1/5 to All on Wed Jul 12 02:50:01 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to Christoph Anton Mitterer on Wed Jul 12 11:20:01 2023
    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)
  • From Simon McVittie@21:1/5 to Christoph Anton Mitterer on Wed Jul 12 12:00:01 2023
    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)
  • From Simon McVittie@21:1/5 to Andrey Rakhmatullin on Wed Jul 12 12:20:01 2023
    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)
  • From c.buhtz@posteo.jp@21:1/5 to All on Wed Jul 12 13:10:01 2023
    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)
  • From Gregor Riepl@21:1/5 to All on Wed Jul 12 12:20:01 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to Gregor Riepl on Wed Jul 12 13:30:02 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to Simon McVittie on Wed Jul 12 13:30:02 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to c.buhtz@posteo.jp on Wed Jul 12 13:30:02 2023
    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)
  • From c.buhtz@posteo.jp@21:1/5 to All on Wed Jul 12 14:00:01 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to c.buhtz@posteo.jp on Wed Jul 12 20:30:02 2023
    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)
  • From Christoph Anton Mitterer@21:1/5 to Andrey Rakhmatullin on Mon Jul 17 23:40:01 2023
    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)
  • From Christoph Anton Mitterer@21:1/5 to All on Mon Jul 17 23:40:01 2023
    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)
  • From Christoph Anton Mitterer@21:1/5 to All on Mon Jul 17 23:20:01 2023
    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)
  • From Andrey Rakhmatullin@21:1/5 to Christoph Anton Mitterer on Tue Jul 18 00:00:01 2023
    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)
  • From Simon McVittie@21:1/5 to Christoph Anton Mitterer on Tue Jul 18 01:30:02 2023
    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)