Mailinglist Archive: opensuse-buildservice (261 mails)

< Previous Next >
[opensuse-buildservice] project dependencies
  • From: Susanne Oberhauser <froh@xxxxxxxxxx>
  • Date: 12 Jun 2008 17:33:12 +0200
  • Message-id: <s2i7icuk6rr.fsf@xxxxxxxxxxxxx>
Hi,

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.

For that reason we linked some packages into the current
openSUSE:Tools:Unstable project and made them build on the old
distros, too.

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?


For example we rely on a specific rails version and on a specific
minimal version of lzma.


So far the problem.


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

Such released versions shall be kept 100% source compatible (API
compatible) and only get bug fixes and 100% backwards compatible
extensions.


For the lack of something like symlinks or consistent renaming of
dependent projects it is reccomended for an upcoming release of a
project (alpha, beta, release candidates, release), to create and use
the final name of the release as soon as the project is considered
stable enough to base other software on it. So if a Foo-3.0 Release
is planned, then even if the real software version still is 2.99-pre4
or such, the project should be named Release-3.0. To tell the _exact_
version, use a version tag inside the packages...

This allows a dependent project to point to another project as early
as it makes sense to use it as base project, without the need to
change names again and again during the release of the base project.

It is proposed to at some point extend the build service to allow for
dependent renames or for 'symlinks' for project names.

===================================================================

comments and feedback welcome :)


S.

--
Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business
OPS Engineering Maxfeldstraße 5
Processes and Infrastructure Nürnberg
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >