Mailinglist Archive: opensuse-buildservice (261 mails)

< Previous Next >
Re: [opensuse-buildservice] project dependencies
  • From: Peter Poeml <poeml@xxxxxxx>
  • Date: Tue, 17 Jun 2008 00:59:42 +0200
  • Message-id: <20080616225942.GB718@xxxxxxx>
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
< Previous Next >
Follow Ups
References