Re: Packages without long term stable releases
On Tue, 05 Apr 2016 at 12:18:18 +0200, Enrico Zini wrote:
> ...and to have a suite, like testing, that:
>
> - does not transition to stable, and is intended to be used as is
> - contains anything that enter testing
> - also contains the packages that would enter testing but do not
> because they are not intended for it
This sounds quite a lot like the "rolling" suite that gets proposed
every few years, with the possible exception that some proposals
for "rolling" have had it bypass unstable while unstable is frozen,
and it sounds as though this doesn't.
I think this would be good to have, particularly if the backports team
can treat it as a valid source for backports to stable, at least for
packages that are not also present in testing. If a package
(let's use your example and say vdirsyncer) is fast-moving and not
suitable for long term support, that doesn't mean it isn't useful
to be able to run a suitably-current version, backported to run
on a "stable core" system. I feel as though that might be a better
model than current stable/volatile for network services and clients
that have to be reasonably up-to-date to remain compatible with the
rest of the world, for instance Bitcoin-like networks, clients for
proprietary protocols, and multiplayer games.
If I understand correctly, a package that is in this new suite but not in
testing can't cause problems with upgrades from stable to next-stable,
because they won't appear in next-stable; that solves one of the
objections to backports from sources other than testing. Backports
from this suite for a package that is *also* present in testing
would still be problematic; if foo_1.0 is in testing and foo_2.0
is in the new suite, and a jessie system installs a foo_2.0~bpo8
backport, then there's no guarantee that an upgrade from jessie to stretch
will see a stretch version of foo (>= 2.0) to supersede the one it got from
jessie-backports.
> I see value in having it in a single suite, because it can be tested for
> consistency as a whole, instead of risking of having different behaviour
> according to what combinations of different PPAs are added to a system.
This new thing could probably be implemented as a bikeshed plus some social
conventions, if bikesheds happen sometime soon, but equally it could be
implemented as an automatically-maintained suite like testing. Either
way, I can see your point about there being value in having the project
agree on a single suite for this (the same way we all share experimental
and jessie-backports), rather than having a series of domain-specific
bikesheds.
S
Reply to: