Re: Creating a new named official debian repository for OpenStack backports (Uploading all of OpenStack to backports)
On 10/03/14 16:32, Gaudenz Steinlin wrote:
> Lucas Nussbaum <lucas@debian.org> writes:
>
>> On 10/03/14 at 22:27 +0800, Thomas Goirand wrote:
>>> On 03/09/2014 12:51 AM, Daniel Pocock wrote:
>>>> One other thing comes to mind: for packages that are slightly more
>>>> volatile than what the backports maintainers expect, or large
>>>> collections of packages like OpenStack, is it worthwhile having some
>>>> alternative to wheezy-backports? E.g. call it wheezy-backports-plus and
>>>> just distribute things from unstable or jessie compiled automatically on
>>>> a wheezy box?
>>>
>>> Actually, now that you make me think about it, I know that FTP masters
>>> have already implemented creating "any" new named repository. So I'm
>>> adding them in the loop to ask for it.
>>>
>>> So, dear FTP masters, would it be possible for you to create some new
>>> repositories for OpenStack? I would need:
>>> - wheezy-havana
>>> - wheezy-icehouse
>>
>> Hi,
>>
>> I'm very much in favor of providing up-to-date OpenStack packages to
>> users of wheezy. The fact that the official OpenStack documentation for
>> Debian points to an unofficial repository is quite sad.
>>
>> However, I'm not sure I understand what problems would be solved by
>> using wheezy-havana, wheezy-icehouse, etc. instead of just plainly
>> wheezy-backports?
>
> I agree with Lucas here. Unless the backports ftpmasters have specific
> concerns (they did not comment until now). I would prefer to have this
> in debian-backports instead of it's own repository.
>
> The only "problem" that could be solved is to lift the requirement that
> packages have to enter testing before going into backports. But to me
> this is actually a feature lacking form the current unofficial
> repository.
>
That is not quite the situation
The problem with distributed systems is that often the version of the
product is more important than the version of the OS.
E.g. I've walked into more than one environment where Ganglia 3.0.7 was
in use. From 3.1.0 onwards, the network protocol is different. So
nobody with a Ganglia 3.0.x environment will use the packages from
stable. If they already have custom built Ganglia 3.0.x binaries on
several other platforms like Solaris and even Windows, they will stick
with that version forever and a day.
Likewise, if somebody has a large network with OpenStack and they just
want some Debian systems to play nicely inside that, they will want
wheezy packages for their version of OpenStack, not just whatever
version of the packages we happen to have in backports.
There are other examples too, e.g. PostBooks. Once somebody settles on
a specific schema version, all systems they use need to have the same
client version to match that schema. Once again, they don't care if the
desktops are some mix of wheezy, jessie and perhaps Ubuntu as well: the
main thing is, the package versions of the PostBooks client code need to
match the DB schema version. Even if we offer PostBooks 4.3 in jessie,
for example, we may need to offer an easy way for people to get 4.1
packages on jessie in case they don't want to upgrade their schema at
the same time they update their OS or in case they only want to update 1
machine per week or whatever.
The solution to all these problems may well be offering different
repositories or having a way to support multiple version in a single
repository
Reply to: