Re: Maintaining intermediary versions in *-backports
On Fri, May 26, 2017 at 11:53:52PM +0100, Ben Hutchings wrote:
> From what I've seen, having LAVA in a third party APT repository
> wouldn't make it noticeably harder to install. You could put whatever
> version of Django you need in that repository too.
Indeed; from reading this entire thread, it seems that when there is
an situation like this:
(a) A fast-moving library which does *NOT* provide API/ABI stability
for longer than N stable release(s), where the time frame of "N stable
release(s)" is not substantially longer than the typical release cycle
for Debian,
AND
(b) A fast-moving set of applications which has a very tight
dependency on the fast-moving library in (a) --- which is likely, if
API/ABI's disappear very quickly, this tends to be likely,
AND
(c) Migrating user/server/application data from one stable release to
another is only supported in an incremental fashion (e.g., you must
update the library and application to version N+1, then let the
application and library run to do the migration, then upgrade to
version N+2, etc.) and it's too hard to make all of this work in the
Debian postinstall script, which is the normal mechanism Debian
provides for this sort of situation.
THEN
It's likely that Debian simply can't support this kind of library plus
application. There is no shame or dishonor in this; it's just a
different set of expectations in terms of developer practices and
user/system administrator expectations.
Even if we can make exceptions for, say, Django and LAVA, what if
there is some other application, call it "Magma" for the sake of
argument, that has a different set of dependencies for a different set
of intermediate versions between Django 1.7 and 1.10. What if it
requires Django 1.9, while Lava requires Django 1.10? Even if you can
twist Backports to work with 1.8 in violation of its policies, we
don't have a Backports'' that can support Django 1.9 for the sake of
Magma. And now let's assume that some sysadmin wants to run Lava and
Magma on the same system. Is that going to be a testable or
supportable situation?
Personally, I see only two really general solutions. Either you do
what old-time Linux "greybeards" have considered good development
practices, which is that you provide backwards compatibility for a
long, long time ("N releases" approaching infinity) and migration
schemes that can roll forward multiple releases --- and, by the way if
you follow the good practices established by Google SRE teams, data
rollbacks MUST be possible as well.
Or you end up going down the Docker container mechanism, where the
potential blast radius coming from incompatible API changes and data
migration practices can be well contained. It might be that with
things like PPA's and very careful system administrator practices
(read: sheer terror during upgrades) you can avoid using containers
--- but in my mind, if web frameworks and applications insist on not
providing good, long-term API backwards compatibility and flexible
data migration and rollblack facilities, containers are the only sane
solution --- and that goes beyond the scope of Debian.
Cheers,
- Ted
Reply to: