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