Neil Williams <codeh...@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 <b...@debian.org> _______________________________________________ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team