Bug#953883: Please backport version 20 for buster

[Enrico Zini]

Package: gunicorn3
Version: 19.9.0-1
Severity: wishlist

Hello,

thank you for maintaining gunicorn.

gunicorn version 19 has issues with the version of tornado currently in
buster: https://github.com/benoitc/gunicorn/issues/2119

Could you please backport version 20, which claims to have fixed them?

Enrico


-- System Information:
Debian Release: 10.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-rc5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gunicorn3 depends on:
ii python3 3.7.3-1
ii python3-gunicorn 19.9.0-1

gunicorn3 recommends no packages.

Versions of packages gunicorn3 suggests:
pn gunicorn-examples <none>
pn python3-pastedeploy <none>
ii python3-setproctitle 1.1.10-1+b2
ii python3-tornado 5.1.1-4

-- no debconf information

[Enrico Zini]

On Sat, Mar 14, 2020 at 02:42:42PM +0100, Enrico Zini wrote:

> thank you for maintaining gunicorn.
>
> gunicorn version 19 has issues with the version of tornado currently in
> buster: https://github.com/benoitc/gunicorn/issues/2119
>
> Could you please backport version 20, which claims to have fixed them?

Thanks for the backport, indeed it fixes the issue, and restarting
gunicorn+tornado services now does not incur in some minutes of
downtime.

I guess this bug could be closed. I noticed that while upgrading to
gunicorn 20, one has to fiddle a bit with packages: I was using
gunicorn3, which is now replaced with gunicorn, and I had to spend some
times figuring out why `apt -t buster-backports install gunicorn3` would
not find the package, while rmadison insisted gunicorn 20 was
backported.

Maybe gunicorn now misses some conflicts/provides/replaces voodoo
towards gunicorn3?


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>

[Chris Lamb]

Dear Enrico,

> Maybe gunicorn now misses some conflicts/provides/replaces voodoo
> towards gunicorn3?

That is extremely likely and, just to be 100% clear, this omission is
not a deliberate one.

I'm inferring from the way you reference it that you have difficulty
getting these incantations right, but I must also admit that I rarely
ever get these right myself without some assistance. Indeed, I see a
"Breaks" that was likely one misguided attempt of mine to address this.

Perhaps we can get some outside assistance on this so we would feel
a bit more confident?


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org 🍥 chris-lamb.co.uk
`-

[Enrico Zini]

On Fri, Mar 20, 2020 at 05:58:05PM -0000, Chris Lamb wrote:

> I'm inferring from the way you reference it that you have difficulty
> getting these incantations right, but I must also admit that I rarely
> ever get these right myself without some assistance. Indeed, I see a
> "Breaks" that was likely one misguided attempt of mine to address this.
>
> Perhaps we can get some outside assistance on this so we would feel
> a bit more confident?

Indeed, this is out of my routine packaging work. I went digging and I
*think* the trick is in policy 7.6.2; at least, I'd give this one a try:


7.6.2. Replacing whole packages, forcing their removal
------------------------------------------------------

Second, "Replaces" allows the packaging system to resolve which
package should be removed when there is a conflict (see Conflicting
binary packages - Conflicts). This usage only takes effect when the
two packages *do* conflict, so that the two usages of this field do
not interfere with each other.

In this situation, the package declared as being replaced can be a
virtual package, so for example, all mail transport agents (MTAs)
would have the following fields in their control files:

Provides: mail-transport-agent
Conflicts: mail-transport-agent
Replaces: mail-transport-agent

ensuring that only one MTA can be unpacked at any one time. See
Virtual packages - Provides for more information about this example.

[Chris Lamb]

Hey Enrico,

> > I'm inferring from the way you reference it that you have difficulty
> > getting these incantations right, but I must also admit that I rarely
> > ever get these right myself without some assistance. Indeed, I see a
> > "Breaks" that was likely one misguided attempt of mine to address this.
> >
> > Perhaps we can get some outside assistance on this so we would feel
> > a bit more confident?
>
> Indeed, this is out of my routine packaging work. I went digging and I
> *think* the trick is in policy 7.6.2; at least, I'd give this one a try:

[..]

Cool, I believe I have addressed that in:

gunicorn (20.0.4-4) unstable; urgency=medium

* Mark that the [Python 3.x] gunicorn binary package replaces the legacy
gunicorn3 one removed in 19.9.0-2. Thanks, Enrico. (Re: #953883)
* Add Bug-Database and Bug-Submit to debian/upstream/metadata.

I will backport this to buster once this migrates to bullseye.


Best wishes,

[Chris Lamb]

Chris Lamb wrote:

> I will backport this to buster once this migrates to bullseye.

I have now done so.