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
(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,

Reply via email to