Re: how to properly split up into python3-foo and foo-util package?
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.
Reply to: