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

Jérémy Bobbio jeremy.bobbio at irq7.fr
Fri Jun 14 17:13:57 CEST 2019

On 14/06/2019 10:25, Denis Laxalde wrote:
> The series looks good to me. It builds fine in a buster sbuild
> (https://jenkins.intra.logilab.fr/job/pkg-from-dsc/404/ for those who
> can read this). So I'll probably apply it soon unless there are further
> comments.
> Looking at what the packaging now looks like, I have a couple of
> questions for the next steps:
> * 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.

> * 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 python3-cubicweb-pyramid should be merged into
>   python3-cubicweb because we dropped all other web backend in default
>   branch.

Nice. I'll work on that soon.

> * 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

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

> * 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.


More information about the cubicweb-devel mailing list