On Thu, 25 May 2017 10:54:51 +0200 Raphael Hertzog <hertzog@debian.org> wrote: > On Thu, 25 May 2017, Neil Williams wrote: > > Any sufficiently complex django application will suffer this > > problem. What is needed is a historical list of migrations and a > > reasonably complex ORM. > > And a postinst that tries to do migrations automatically. That's not > the general case with Django applications. > > In most cases, the migrations are left to the user and the application > should document its expectations to be able to run its migrations > successfully which in turn should be documented in NEWS.Debian so that > they are shown to the end-user. Seriously? ? Is this documented somewhere ? This would break lava-server in Debian when testing in piuparts and any package using django in anything more complex than a trivial demo. All the migrations need to be run just to allow the scheduler daemon to start and if it cannot start, the package installation will fail. https://staging.validation.linaro.org/scheduler/job/174935#L3932 We have 70+ migrations to apply. LAVA is not a simple webapp that sits dormant on the filesystem until the admin restarts apache. There is a constantly running scheduling daemon which processes the queue and assigns devices to test jobs, then a separate daemon to monitor those test jobs as they run on remote machines. There is also a notification daemon listening to activity from the other components. Code deployed as part of the package determines how new test jobs are parsed and processed and this must be in sync with the current state of the database. This is a system processing thousands of test jobs each day using over 100 different devices. There are other systems which depend on getting fast responses out of the data to feed that back to kernel developers when checking for regressions and doing bisects. The entire system needs to auto-update transparently and without failures. Applying security fixes and upstream releases with minimal admin interaction (there are only 3 admins and most of the test devices are early prototypes which require a lot of hand-holding). The only interaction during an upgrade should be to update some device configuration and possibly upgrade a dependency from backports to make it easier for apt to calculate the upgrade path. > So the problem is not as bad as you seem to imply AFAIK. Is it still practical to have 1.8 in Stretch? That would solve this bug. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp0d8MikLwWg.pgp
Description: OpenPGP digital signature