Re: Should fast-evolving packages be backports-only?
On 11/11/14 14:30, Rebecca N. Palmer wrote:
> It has been recently stated [0-1] that backports is enabled by default
> in Jessie.
>
> 1. Does that mean that if pkgX is in jessie-backports but not jessie,
> "apt-get install pkgX" will install it from -backports?
>
> 2. If so, when (if ever) is it appropriate to deliberately invoke that
> behaviour by removing pkgX from jessie?
>
> 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
Maybe also
d. packages that the security team decide to support by using
upstream releases (in other words, should the browsers be distributed
through backports only?)
One big question that arises then (and what I asked in a separate thread
about the browser-related packages but it is relevant to other classes
of package too) is compatibility
- if package foo is allowed to change, do all packages broken by the
change (e.g. browser plugins) get to be uploaded again too?
- if some package hides the complexity of the change and the maintainer
has kept the API stable so that dependent packages don't break should it
be looked on more favorably and allowed to be updated in stable too?
Personally, I feel that having backports enabled by default is only part
of the solution to the challenges with volatile packages but it may be a
step in the right direction.
I also feel that this is something that impacts each maintainer and each
user differently. Some people are working in parts of the system where
the freeze concept really is the most important thing. Other people are
working on applications where network compatibility is the most
important thing (as it is with communications) and people simply won't
use the package or won't be able to use it successfully if is not
updated. Ultimately, with more and more packages being in this category
as the world becomes more networked/cloudified, this impacts Debian's
relevance for whole groups of users.
>
> The advantage of doing so (over having both the old version in jessie
> and the new one in jessie-backports) is that non-technical users (who
> may not know that backports exists) get the new version they probably
> want; the disadvantage is that users who explicitly want stability can
> no longer choose it (except by pinning or using snapshot.debian.org,
> which also block security updates of that package).
>
> In the long run it may be a better idea to have these packages suggest
> upgrading to -backports in their "this hardware/protocol
> version/option not supported" error message, or on startup if there is
> no easy way to identify attempts to use the newer features, but it is
> too late to do this for jessie.
>
> (Release team have already ruled that a. (#767961) and b. (#768933)
> are not valid reasons for freeze exceptions; I guess this would also
> forbid stable updates)
>
> [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html
> [1] My own sources.list has
> # jessie-backports, previously on backports.debian.org
> # Line commented out by installer because it failed to verify:
> #deb http://ftp.uk.debian.org/debian/ jessie-backports main
> but https://lists.debian.org/debian-user/2014/09/msg01174.html reports
> getting one with that line uncommented
> [2] https://lists.debian.org/debian-release/2014/11/msg00866.html
>
>
Reply to: