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
