Re: python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED
Raphael Hertzog <hertzog@debian.org> writes:
> I don't understand how Brian came to this conclusion either, unless he's
> speaking of uploading to backports version of packages in stable that
> would be broken when running with Django from jessie-backports.
Lets say Django 1.10 enters backports. This breaks my hypothetical
package which is stable. Or maybe it is already in backports, doesn't
matter. So I need to upload a new version to backports from testing.
Unfortunately, the new version of this package in testing depends on
pytest-bdd (lets pretend this is available in testing). So I have to
backport this package. However pytest-bdd depends on python-glob2 and
python-parse-type, so I have to backport those packages first.
So instead of backporting just one package, I end up backporting 4
packages.
This is just a simple example, I have had worse problems in the past.
> There's nothing messy for my backport users (there are many persons
> who explained that they are happily using my backport which benefits from
> security upgrades), there's nothing messy for the contributor doing the
> work (aka me, except the fact that I have to deal with this thread). The
> only mess is the one that you are seeing and your only words to describe
> that mess is "you are not following the policy".
I am going to switch sides here (am I allowed to do this?), and try to
guess:
* If we enforce the rule that backports must match the version in
testing, it becomes easy for an automatic process to work out which
backports are out-of-date.
* There was some talk somewhere in these threads (which I glanced at way
to quickly) about updating the BTS to properly support
backports. Possibly this was designed with the assumption this rule
would stay in place, and now there are exceptions it makes things
messy. Or maybe there are technical difficulties trying to get
versioning to work correctly without this rule.
--
Brian May <bam@debian.org>
Reply to: