Re: Should fast-evolving packages be backports-only?
On Tue, 11 Nov 2014, Daniel Pocock wrote:
> On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
> > 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...
> >
>
> That is not so easy though or it may have side effects
>
> For example, if a library changes implementation details but the public
> API and ABI does not change and no other dependent packages need to be
> recompiled then it should be OK for those dependent packages to live in
> stable.
>
> Does that mean the maintainer has to put their libfoo-dev in stable
> while keeping their volatile libfoo1 in backports?
Looks like a "let's not go there" kind of deal. Make it simple, so that it
has a non-zero chance of flying and all that. After we have some experience
with it in practice, we revisit the issue.
--
"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: