Re: Creating a new named official debian repository for OpenStack backports (Uploading all of OpenStack to backports)
On 11/03/14 09:47, Lucas Nussbaum wrote:
> On 11/03/14 at 09:37 +0100, Alexander Wirt wrote:
>> On Tue, 11 Mar 2014, Lucas Nussbaum wrote:
>>
>>> On 11/03/14 at 13:57 +0800, Thomas Goirand wrote:
>>>> Second, there's only a single "wheezy-backports". Therefore, I can't
>>>> have OpenStack Grizzly, Havana and Icehouse hosted at the same time by
>>>> Debian. Same issue in Sid/Testing by the way. This is a huge problems
>>>> for integrators/users, because they should be the one deciding when to
>>>> upgrade their cloud IaaS. If I decide to override Havana by Icehouse
>>>> (for example), then I can't provide security updates for Havana anymore
>>>> in Debian.
>>> Have you considered solving this using the way we usually allow several
>>> versions of the same software in Debian, that is, by suffixing the
>>> package name with the version? (gcc4.7, gcc4.8)
>>> I'm not completely convinced that we need several versions of OpenStack
>>> at the same time in a backports-like repository, but if you want to
>>> achieve that, that's a way that doesn't involve separate repositories
>>> for each release.
>> As long as they are also in testing.
>>
>> By the way ~180 Source packages? Are you guys sure. I personally think a software
>> that needs 180 specific versions of source packages ridiculous.
> Well, it probably makes sense to see OpenStack as something like GNOME
> or KDE here, in terms of dependency graph...
>
Gnome, too, has to be treated like a distributed system if NFS home
directories are in use
A site may well want all users to have the same Gnome version (and
compatible artifacts in their home directory) even if some desktops are
on stable and others on oldstable
As for OpenStack, I don't think they need to simultaneously install
different versions on the same box, so it is not like having both gcc4.7
and gcc4.8 on the box at the same time. A machine will only have the
icehouse version, for example.
Another issue here: using names with version numbers (e.g.
src:resiprocate-1.9) means everything goes back to the NEW queue, more
tedious for the FTP masters and more delays before people really start
testing the packages.
Reply to: