On Wed, 8 Feb 2017 21:17:14 +0000 Holger Levsen <hol...@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/
pgpnsr3Y8PTiN.pgp
Description: OpenPGP digital signature
