Although yes package managers do know how to pick up a version, they sometimes 
do this automatically with a newer version (if u leave out the version).

This then brings back the problem of how exactly do people with other 
distributions know what version is going to work if the package manager selects 
the versions. Having it in the file at least gives people the knowledge that 
the given version was used by developers for creating a given openstack release 
and should be stable if they ever want to install that release in the future.

Distromatch might make sense, but it still doesn't resolve the version issue (I 
am not an expert on distromatch).

Right now this is (but hopefully won't be in the future) a big pain when trying 
to get openstack running (or even developed on) in another distribution. How do 
we know which version developers have been using, well we go to ubuntu 11, 
check that version and hope that the version is available in the other 
distribution (this is problematic since if its not and say its a python 
version, then u have to pray that the package will have all the necessary 
functions/classes - since python won't check until called, thanks to duck 
typing). So even though yes there are a lot of versions specified and a lot of 
packages specified it does seem like this is what is needed for a large project 
like openstack.

I've seen ubuntu switch out versions sometimes though (ie blah-ubuntu1 to 
blah-ubuntu2), so I am not sure about 1 version, 1 active version maybe, but 
for a large project should the openstack community just expect that 
blah-ubuntu2 will work for everyone (hopefully nothing major changed between 1 
and 2). Since everyone at openstack was say developing with blah-ubuntu1, 
changing to blah-ubuntu2 shouldn't happen unless its really needed since this 
may cause regressions or other problems.

-Josh

On 1/24/12 2:57 AM, "Bernhard M. Wiedemann" <ubuntu...@lsmod.de> wrote:

On 01/17/2012 08:20 PM, Joshua Harlow wrote:
> My goals were/are/(may continue to be, haha) the following:
>
>
>   1.  Add in enough abstraction so that you can look at how each component is 
> installed/uninstalled/started/stopped by looking at a single file (maybe 2 
> files)
>   2.  Have the ability to start/stop in different manners (not always screen)
>   3.  Have the ability to have pkg/pip installation (and definition separate 
> from the main code, already starting to be done), in more than 1 distro.
>      *   This allows others to easily know what versions of packages work for 
> a given openstack release for more than one distro (yes that's right, more 
> than ubuntu)
>   4.  Increase the level of documentation (probably not going to be in the 
> end, inline like what is in devstack, since that just doesn't seem 
> maintainable in the long-term)
>      *   This may mean having documentation created similar to nova, glance, 
> as a separate documentation document/page....
>
> Still be simple "enough" to run and use so that the non-python dev can 
> install from trunk without having to understand what is going on.
>
> -Josh

I was looking into how easy it would be to support openSUSE / SLES in
devstack v2 and saw that there are currently 17 json files containing
package names (with 293 versions) for ubuntu-oneiric and rhel-6.
Shouldn't there be some better way than to list all this redundant
information there, which makes it hard to maintain/extend?

E.g. the distro's package manager already knows about dependencies and
usually has just one version of a package for a given distribution anyway.
And there was even one project about mapping package-names of one Linux
distribution to another:
http://enricozini.org/2011/debian/distromatch/
So it should be possible to build upon it, and just list packages once.

Ciao
Bernhard M.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to