Re: Should fast-evolving packages be backports-only?
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?
Reply to: