nginx package signature guarantees with Xenial?

[Robie Basak]

Hi Jeff,

Thank you for getting in touch.

I think the ubuntu-server mailing list is probably more appropriate to
reach the right audience for this discussion, so I'm moving the thread
there. Please reply to ubuntu-server only.

I'm going to skip ahead in your message a bit.

On Thu, Jun 23, 2016 at 04:48:21PM -0400, Jeff Kaufman wrote:
> (One thing that this would mean would be not updating the version of
> nginx that's included in a release, since that's part of the
> signature.  Switching from 1.9.15 to 1.10.0, which you did right after
> releasing, is the sort of thing this would preclude.)

Unfortunately I think this rules out your proposal. We do what we call
"micro release updates" (MREs) when appropriate. Generally, if an
upstream has a stable release branch, have a policy of applying only
bugfixes to that branch, and has decent test coverage, then we're open
to using it.

We rely on upstreams for bugfixes quite a bit. So I don't think we
should close the door to this possibility. Fundamentally I don't think
we're in a position to make the kind of commitment you're requesting
because we don't write the updates.

> I work on ngx_pagespeed, which is an open source nginx module that
> rewrites web pages so they load faster.  To install ngx_pagespeed on
> Ubuntu site-owners currently need to build our package from source,
> but they would find it much easier if we could ship binary packages
> that they could install.  Nginx didn't previously support these
> packages, but they added it recently and Xenial is the first release
> of Ubuntu that includes a recent enough version of nginx to make this
> possible.

Have you considered adding your module to Ubuntu's repositories? Is
there any reason you couldn't maintain them in xenial-backports for the
benefit of Xenial users, for example?

IMHO heavy dependency on an exact version is never good - it's better
for the wider ecosystem if there is focus on the actual ABI instead of
some signature that gets bumped "too often" in order to more easily
allow external modules such as yours. But an example of another package
where this kind of thing happens is pinba-engine-mysql, which you might
want to take a look at to see the packaging mechanisms used. Right now,
when the Ubuntu security team update MySQL to a newer upstream version
(from the same upstream stable branch), they also issue a "no change
rebuild" update of pinba-engine-mysql. This way users don't need to
compile anything and it all just works.

One disadvantage is that if pinba-engine-mysql failed to build with a
newer MySQL, then the security team would presumably end up a little
stuck (and would probably be forced to update MySQL anyway, breaking
pinba-engine-mysql, to minimise vulnerability exposure to users). But
really this is just a more common case of the general problem of ABI
breakage in any potential update.

> Nginx dynamic modules are pretty different from Apache ones, or other
> ones that go via an ABI.  Instead of a defined interface they use a
> very inclusive signature, and require modules to have been compiled
> against a copy of nginx that has the same signature as the host.
> Would you be up for committing not to make changes to the signature of
> nginx in a release, over the course of the several years of
> maintaining it?  If so we could release one module compiled for
> "Ubuntu 16 LTS" and then in two years start maintaining an additional
> module compiled against "Ubuntu 18 LTS".  Otherwise I'm not sure how
> to ship binary modules for Ubuntu.

Note that it's 16.04, not just 16. 16 will be ambiguous when a
subsequent 16.10 is released.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20160624/bf5d0aed/attachment.sig>