Hi Susanne, On Thu, Jun 12, 2008 at 05:33:12PM +0200, Susanne Oberhauser wrote:
during the 1.0 release of the build service we stumbled accros the need for more recent base packages for older OSs; e.g. obs-* needs a current rails and python if used on the old sle10.
Nitpick: no new python is required. (Just some modules.)
For that reason we linked some packages into the current openSUSE:Tools:Unstable project and made them build on the old distros, too.
I must say, if everybody does that, it starts to get hairy. Now openSUSE:Tools suddenly has a python-setuptools package. (And even yum.) This is evil, because I suddenly get python-setuptools packages from different sources. Even though the one might be a link onto the other, I can't know this as user and I need to to check if they match and you haven't introduced any incompatibility. Since no new python is required (see above), and you just need some modules, why not simply ask the user to subscribe to the project which already *offers* those -- devel:languages:python? In fact, the devel:languages:python maintainers (myself is included there) try hard to provide stuff for old distribution _and_ keep it compatible to the original distro packages. Also: I use a custom yum package which I build in my home. I now suddenly get a newer yum package offered by openSUSE:Tools, which I don't want and which I have to exclude therefore. Why not move the yum into a Yum project? A Yum project would seem more generally useful to me, than a yum in home:something, one in openSUSE:Tools, and one elsewhere. That project could also include the createrepo which is required by the build service. That's my point of view :-)
Now we're about to release 1.0 and we wonder what to do with these links.
We believe, that _ideally_ the respective original projects should take the patches for other distros so we can base our openSUSE:Tools release on those and get rid of the links.
Now here comes the challenge: how can we ensure the underlying projects won't break our _release_, our reccomended official version of the obs randomly, by updating their packages later, introducing regressions or incompatible changes?
So simple: 1) wait if it actually happens at all 2) talk to the maintainers so they are aware 3) move on. ;-) We still could link a package with patches into openSUSE:Tools _then_.
Here is a proposal for solution, if someone has a better, simpler, more usefull approach, welcome :)
Software Integration using the obs ==================================
To integrate and release interdependent software projects with the openSUSE build service, the following conventions are proposed to protect depending projects from regressions after test and release:
Officially released versions of projects shall be named like this:
$project:Release-$version
examples:
openSUSE:Release-11.0
openSUSE:Tools:Release-1.0
I don't like this proposal. I really don't think that anybody needs different releases of the build service at all. I don't think we are going to (nor need to) maintain old releases in "maintenance-mode", we will rather move on. That's my feedback :-) Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development