Re: Should fast-evolving packages be backports-only?
On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
> Possible candidates:
> a. Packages that work closely with hardware, where old versions
> don't work with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network
> protocols, where you need the same version as the people you are
> communicating with (possible example: jscommunicator [2])
> c. Packages that are generally rapidly improving, and are typically
> used where this improvement is more important than stability
We used to have the volatile archive for software that absolutely needs to
be updated very often (like virus scanners). We now have the
"stable-updates" archive for this.
https://wiki.debian.org/StableUpdates
If packages are taking too long to go from stable-proposed-updates to
stable-updates, that's something we could talk to the release managers
about.
Although, I am *sure* lack of widespread use (and therefore testing) of
stable-proposed-updates by users and developers (HINT HINT HINT HINT) is one
of the reasons.
However, candidate packages due to reason (c) above really are a problem,
IMHO they shouldn't be in stable in the first place. backports seem like a
better solution for this case. However, we'd need to add further
requirements: packages not built from the same source package cannot depend
on such "never-for-stable" packages, and we must tag them somehow so that
they never get released to stable...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: