[Python-modules-team] Bug#863267: Bug#863267: Miscalculates MigrationHistory dependencies between multiple django apps - regression from 1.8

[Brian May]

Neil Williams <codehelp at debian.org> writes:

> django.db.migrations.exceptions.InconsistentMigrationHistory: Migration
> lava_scheduler_app.0001_initial is applied before its dependency
> linaro_django_xmlrpc.0001_initial on database 'default'.

Ok, I see what is going on now. Untested theory at the moment, but it
fits the symptoms.

./lava_scheduler_app/migrations/0001_initial.py contains:

    dependencies = [  
        ('auth', '0001_initial'),  
        migrations.swappable_dependency(settings.AUTH_USER_MODEL),  
        ('linaro_django_xmlrpc', '__first__'),  
        ('dashboard_app', '__first__'),  
    ]  

My reading of this is that this means this migration depends on the
first migration from 'linaro_django_xmlrpc' to be already
applied. However on Jessie, 'linaro_django_xmlrpc' has no
migrations. Hence I suspect whatever version of Django that installed
this migration to be buggy, because it didn't check the dependencies
could be satisfied. Or maybe this was considered OK at the time.

This migration is already applied when we come to do the new migrations
for Django 1.8 or Django 1.10

Django 1.8 doesn't care that the first migration for
'linaro_django_xmlrpc' hasn't been applied yet. As a result, it can fake
the migration and everyone is happy.

Django 1.10 does care. It says the database is broken because the
prerequisite for this migration was never applied. It does this check
before applying any migrations.

I don't know for sure what is correct behaviour here. However I am
inclined to think maybe this isn't a Django 1.10 fault, because the
migration in Jessie clearly says it depends on a migration that was
never applied - because it doesn't even exist at this point.
-- 
Brian May <bam at debian.org>