Den 5 maj 2013 06:25 skrev "Clint Byrum" <firstname.lastname@example.org>:
> On 2013-05-04 20:09, Charles Plessy wrote:
>> Le Sun, May 05, 2013 at 04:31:12AM +0200, Lucas Nussbaum a écrit :
>>> Another problme is that it would not benefit from possible security
>> There are security updates on wheezy-backports, but I assume that you mean
>> that: if 1) we do not add wheezy-backports to /etc/apt/sources.list and 2) if
>> there is a security update, then it will be less straightforward for our users
>> to benefit from it.
>> One solution would be to add wheezy-backports to /etc/apt/sources.list. By
>> default, it will never cause the installation of backports on the system unless
>> the administrator specifically requests it. Because wheezy-backports are
>> configured with "ButAutomaticUpgrades: yes", security updates for the
>> backported cloud-init will come the same way as security updates for packages
>> in Wheezy. Apart from the goal of being as similar as possible as systems
>> installed with Debian-Installer with default choices, I do not see
>> disadvantages for doing so.
>> If the cloud-init backport works well, another solution would be to add
>> cloud-init to Wheezy in the next point release. (In know that it is not on
>> this list that it has to be formally proposed, but I think that this request
>> would only have a chance to pass if it is largely consensual here, so let's
>> discuss it here first).
> Add cloud-init to the point release. IMO, its important enough that it should be added before the point release, but either way, just get cloud-init into wheezy. Failure to do this means the cloud images will either be special (with backports) or mostly unusable for a huge portion of users.
A goal should be to try to get cloud-init into stable. But that is hard, I guess. Have adding a package after a release ever happened?
Packages that are in Debian can always get bug fixes, as long as any changes doesn't change the cli- or configfiles API in incompatible ways. So to old cloud-init in Debian stable should not be a big problem.
Another goal should be to make the Debian installation as similar to a normal Debian installation as possible. Because that will make it less of a surprise to administrators used to Debian. That speaks against having backport in the image.
Any change compared to a clean minimum Debian is bad, and unless absolutely needed should be avoided. There are nothing that forbidding others to make other changes to a image, adding things. But that isn't pure Debian any more, it will be like Cloudian, Ubuntu or Mint etc. And that isn't a bad thing, just not pure Debian. Maybe a Debian blend though, which could be a solution to some problems here.
That said, if backports are needed, I think that it would be ok to at least recommend that in the documentation and the Debian Wiki pages.
And lastly, this is only my opinion. Debian is about doing. So I will and can't do anything else than chip in my opinion, as I have not written any code.
So please ignore this if it will hinder anyone from actually do the needed work. ;-)