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 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
> 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.
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.
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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789214
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?
Cheers,
Thomas Goirand (zigo)
Reply to: