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.