Le Thu, Nov 26, 2015 at 11:40:01AM +0100, Thomas Goirand a écrit : > On 11/25/2015 04:06 PM, Charles Plessy wrote: > > > > in practice, the Debian "Stable" images for AWS and now Azure contain bits > > that > > are not from Stable, for instance the cloud-init backport. Thus, the > > current > > consensus is to call Debian "Stable" the images where all extra additions > > are > > justified. > > There's no consensus with that at all. If you're taking stuff from > backports, then the image can't be called stable, because that's not the > case. And it's not because it pleases you to do so that you should do > it. The IMO only way to fix the issue is to get the packages fixed in > Stable.
Hi Thomas, consensus does not mean unanimity. I wrote "consensus" because at least the AWS and Azure images contain backports, and disagreements over this not go as far as taking action so that the Jessie images are either renamed or deleted. So practically, everybody has at least enough agreement to let things be done that way. But of course, it would be better if we would not need to use backports. Let's see if something positive emerges from the discussion that you started (thanks !) on debian-devel about Stable updates. > The issue isn't only about the name, and where we put the limit (because > the "almost stable" is really a very fussy definition...). But the fact > that as soon as you add a single package from jessie-backports, you > should also add these repositories configured into the image, to allow > to have updates. And effectively, this means the image is using > stable+backports. Indeed, in order to keep the possibility for security updates, the backports repository needs to be enabled. Actually, during the Jessie release cycle, we even asked that backports are enabled by default, and for some time it had been accepted, and was only reverted at the end of the cycle by Cyril Brulebois (see https://bugs.debian.org/764982 for details). The main argument against enabling backports by default is that, when a package is not present in the base suite, apt will install it from backports without requiring an explicit selection of the backports suite (for instance with the -t option). Thus, a user may install without realising it a package that does not have the level of support that we provide for the Stable release. In the case of cloud images, wouldn't that problem be solved by pinning the backports suite at a low priority, and pinning the installed backports (cloud-init, etc.) at a higher priority ? More in general, it seems to me that the best solution to allow enabling backports by default would be to change APT's behaviour so that installation of new packages from the backports suite always require that the suite is explicitely selected. Does somebody know if this has already been discussed somewhere ? Have a nice week-end, -- Charles