[PATCH 00 of 11 cubicweb/debian] Update Debian packaging for 3.27

Denis Laxalde denis.laxalde at logilab.fr
Tue Jun 18 14:50:38 CEST 2019

Jérémy Bobbio a écrit :
> On 14/06/2019 10:25, Denis Laxalde wrote:
> > * python3-cubicweb has explicit Depends:, shouldn't we only keep
> >   ${python3:Depends} and let pybuild generate dependencies from
> >   requires.txt?
> It would be more idiomatic and would prevent outdated dependencies.

Let's do this then :)

> > * what about recommends and suggests: should we keep them (they are
> >   probably outdated)?
> Moving to Python 3 could be a good opportunity to start fresh.
> This is where writing more tests for autopkgtest could help in the
> future by testing what happens when Recommends are installed.
> I would appreciate hints if you have any idea of what could be done.

I think Recommends should mirror the "extras_require" from setup.py.
I.e. packages that are needed to use some parts of the framework but not
needed to use its core.

I see ${python3:Recommends} and ${python3:Suggests} substvars exist
according to dh_python3(1). Haven't tried them, but maybe this is what
we want?

About autopkgtest setup, I'll first need to get familiar with this tool
to provide more information.

> > * Does the cubicweb-ctl package still makes sense? /usr/bin/cubicweb-ctl
> >   is shipped with python3-cubicweb and there is not init script or
> >   systemd service file installed.
> The main question around this is co-installability. Could a system
> have both python-cubicweb and python3-cubicweb installed at the same
> time?

Yes, I see no reason to prevent this. But this only applies for versions
where we ship both packages for both python2 and python3 (e.g. branch
3.26, but not branch default). So in default branch, we should make
python3-cubicweb conflicts with python-cubicweb.

> In that case, having the script in an extra package makes this possible
> by deciding on which Python interpreter it'll use. Although, it begs the
> question, which one should it be?
> For the sake of simplicity and predictability, I would make cubicweb-ctl
> part of python3-cubicweb and prevent co-installability. But I guess it's
> best to reason with #17207330 in mind.
> Background: https://wiki.debian.org/Python/LibraryStyleGuide#Executables_and_library_packages

Ok, I'd vote for keeping the cubicweb-ctl binary package, with a
Depends: python3-cubicweb in default branch and Depends: python-cubicweb
in 3.26 branch.

In any case, this is not a big deal because, technically, "cubicweb-ctl"
is just "python -m cubicweb".

> > * Can we drop the transitional packages?
> Actually it depends on the upgrade policy. Should systems with cubicweb
> installed get python3-cubicweb in the future? Or must they perform a
> manual upgrade? In that case, I guess it's a good time to drop them.

Let's drop them!

More information about the cubicweb-devel mailing list