Re: About non-Stable files in Cloud images: create a Blend ? Distribute image builders on ftp.debian.org ? More liberal Stable updates ? (Re: Debian images on Microsoft Azure cloud)
On Thu, Nov 26, 2015 at 5:40 AM, Thomas Goirand <email@example.com> wrote:
> On 11/25/2015 04:06 PM, Charles Plessy wrote:
>> Le Thu, Nov 12, 2015 at 04:01:50PM +0100, Thomas Goirand a écrit :
>>> Unfortunately, "driven by technological necessity", or the size of
>>> changes, isn't a point of argumentation (see my previous mail). All of
>>> the packages must be taken from stable, unchanged, and if some are taken
>>> from backports, this must be explicit, and the image shouldn't be called
>>> "stable Debian". Official, yes, but not stable (maybe stable + some
>>> backports would be ok...).
>> Hi Thomas and everybody,
>> 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
> 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
> 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
> Which is why I am insisting so much that the stable release team
> approved my fixes for cloud-init in Stable. Just ignoring the issue of
> the buggy startup of cloud-init in Stable, and hoping that we fix bugs
> in jessie-backports, then use that, doesn't cut it. Bugs in stable
> should be fixed, that's it.
> I would by the way very much appreciate a bit of support to convince the
> release team that we need to go forward in this bug report:
> tl;dr: I'm asking to add some .service files to cloud-init in stable,
> because the way systemd schedules things with initv scripts, the order
> is just wrong, and things may break. On a vanilla OpenStack image,
> that's fine, but as soon as you add new daemons and services, it starts
> to show.
> So the only way to fix things is to get the .service files added to
> Jessie. The issue has been pending since the 19th of June, with still no
> decision from the release team.
>> Remains the case of packages pulled from stable-backports or even unstable.
>> Calling the resulting system "Stable plus backports" would be misleading, since
>> this does not convey the information that the amount of backported packages
>> is kept to the strict minimum.
> Never the less, you must activate the repositories from
> stable-backports, and that's effectively what the image becomes.
>> In the end, I start to think that it would be a good idea to create a Blend as
>> suggested earlier on this list.
> Feel free, by all means. But then it's not pure Debian anymore, it's a
> derivative (or a blend if you want to call it this way).
>> So if the needs of cloud images on various platforms are similar enough, how
>> about creating a non-Pure blend called "Debian Cloud" ? This is much more
>> self-explanatory than "Stable (plus backports)", and it could start as just a
>> page on www.debian.org explaining what images are available, and what the
>> differences are compared to Stable. What do other people think about this ?
> I very much would prefer if we had everything in Debian Stable, and aim
> towards that goal. Hopefully, this will be the case for Stretch for
> images which are non-openstack as well.
>> Lastly, a more radical solution would be to allow Stable updates of key
>> packages, even when they do not conform with the usual policy for Stable
>> updates. In the case of cloud-init for instance, I think that it would be
>> possible to coordinate such updates on this list, without rushing and with
>> giving all needed attention if there is feedback requesting to not do the
>> updates. This may open the possibility to have 100 % Stable images.
> This is exactly what I think should happen. Though for that, we need to
> convince the release team. This isn't easy to do so. Perhaps opening a
> thread on debian-devel, and trying to gather a consensus would ease the
> discussion with the release team on updating these key packages.
> On the Stable release, we have updates for the Kernel to add new
> drivers, previously not supported. I really consider that the support of
> new clouds (for example through an update of cloud-init) is exactly the
> same kind of thing. Cloud-init is IMO just like a driver for the cloud,
> which we should be allowed to update, just like for the kernel, and as
> soon as the diff is minimal. I have very little hope for introducing a
> new upstream release (I'm almost sure the release team would just refuse
> that), though perhaps we can do a bit patch of backports.
> Your thoughts anyone?
I think that if PPAMAIN existed we might not be having this
discussion. (Or at the very least it would be a much shorter
As you know, public and private cloud APIs move at a much faster rate
than our ~2-3 year release cadence.
We all need a way to bring in newer cloud enablement packages. It
seems to me our theoretical options are either via backports,
stable-updates, or PPAMAIN, as I don't think convincing the release
team to make an exception for cloud enablement packages is likely to
work. Perhaps they will grant us an exception, where the package in
question is completely broken, but even then it will likely be an
uphill battle, as we are likely to have dependencies that also need
> Thomas Goirand (zigo)