[Piuparts-devel] Bug#847277: lava-server: fails to upgrade from jessie to stretch

Wed Feb 8 21:58:58 UTC 2017

On Wed, 8 Feb 2017 21:17:14 +0000
Holger Levsen <holger at layer-acht.org> wrote:

> On Wed, Feb 08, 2017 at 09:03:20PM +0100, Andreas Beckmann wrote:
> > > (alternatively, admins can just install python-django
> > > python-django-tables2 from jessie-backports and run `lava-server
> > > managedb migrate` manually.)
> > > There's nothing wrong AFAICT with requiring a step via
> > > jessie-backports.  
> > That's a *very* uncommon requirement (lava-server is the first
> > package doing this).  
> 
> yeah, besides being pretty uncommon it's also pretty wrong I think,
> as it implies the version in jessie-backports cannot be upgraded to
> the version in stretch, as this would make the intermediate step in
> jessie-backports mood… :-)

I need to clarify this.

* lava-server is the same version in jessie-backports as in stretch. [0]

* python-django is *not* the same version [1] because jessie-backports
  has the LTS. Both jessie and stretch have intermediate releases from
  django upstream (1.10, incidentally, will run out of security support
  during the lifetime of stretch just as 1.7 in jessie already has). The
  LTS is not suitable as a security update because of the changes
  needed in reverse dependencies between 1.7 and 1.8 and then from 1.8
  to 1.10 which would make all reverse dependencies uninstallable and
  unusable as soon as any of the services are restarted.

* lava-server is only needed in the list of packages to get from
  jessie-backports because it's the simplest way to ensure that the
  following command works: `lava-server manage migrate` - it is this
  command which uses the support in django1.8 LTS to handle the
  migrations inside django to allow the upgrade to lava-server
  2016.12-1~bpo8+1 and then on to django1.10 and 2016.12-1. It is django
  which makes it impossible to go directly from jessie, 1.7, to
  stretch, 1.10 without a route via 1.8 in jessie-backports.

[0] https://tracker.debian.org/pkg/lava-server
[1] https://tracker.debian.org/pkg/python-django

> That said, I can see how this could be more *convinient* (in the case
> where there are 3 very different versions involved, in stable,
> stable-bpo and testing/future stable but IMO this is broken
> unreliable design. What if the version in stable-bpo needs to be
> upgraded due to security issues and the only suitable version is the
> one in testing?)

The version of django in testing (1.10) *cannot* be used as a security
update for jessie - it is, by definition, not a suitable version
because it will break all reverse dependencies already in jessie.

There is a security update for django in stable-sec, it's based on 1.7.
The jessie-backport was updated to 1.8.15-1~bpo8+1 [2] *after*
1:1.10.1-1 migrated to testing. [3] The upload to backports was itself
a new upstream security release.

[2] https://tracker.debian.org/news/813577
[3] https://tracker.debian.org/news/796357

> That said, there is nothing wrong with this is this is *optional*.

It sadly isn't optional. It is compulsory for all paths from
lava-server in jessie to lava-server in stretch.

It's an inevitable consequence of having persistent (valuable) data
which is closely modelled by code which is in ongoing development.

The only Debian-like way to deal with this would be to have source
packages for python-django-17 in jessie, python-django-18 in
jessie-backports and in stretch and python-django-110 in stretch with
corresponding binary package name changes. IIRC the django maintainers
in Debian consider that there is insufficient manpower to follow this
approach. lava-server gets tested against both 1.8 and 1.10 anyway as
the majority of users are running lava-server on jessie with backports,
not stretch or unstable but developers are using unstable.

It's one of the reasons why we had to drop Ubuntu support for
lava-server - we don't have the manpower in the LAVA software team to
test on a matrix which combines Debian and Ubuntu versions of django.
(The last version of lava-server for Ubuntu was for Trusty 14.04LTS and
it was precisely these database migration issues which forced us to
seek removal of lava-server from Xenial 16.04LTS)

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20170208/acb416f5/attachment.sig>