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.
Le jeudi 12 juin 2008, à 17:33 +0200, Susanne Oberhauser a écrit :
Officially released versions of projects shall be named like this:
$project:Release-$version
examples:
openSUSE:Release-11.0
openSUSE:Tools:Release-1.0
Hrm, if all projects do this, won't we end up with tons of repositories?
Vincent
On Friday 13 June 2008 10:57:05 Vincent Untz wrote:
Le jeudi 12 juin 2008, à 17:33 +0200, Susanne Oberhauser a écrit :
Officially released versions of projects shall be named like this:
$project:Release-$version
examples:
openSUSE:Release-11.0
openSUSE:Tools:Release-1.0
Hrm, if all projects do this, won't we end up with tons of repositories?
Yes. This is not a big problem (except for storage), but the question is we want to force the user manually to switch repos on updates.
I think in most cases a :Stable and a :Unstable makes more sense.
bye adrian
Adrian Schröter adrian@suse.de writes:
Yes. This is not a big problem (except for storage), but the question is we want to force the user manually to switch repos on updates.
I think in most cases a :Stable and a :Unstable makes more sense.
Let me try to understand what that means.
So I release some software, Bar-o-meter, 1.0.
I've released and tested Bar-o-meter with some other project Foo-foo, Version 1.7, which is what's currently in Foo-foo:Stable.
Now Foo-foo:Stable is updated to 2.0, which breaks APIs. Now I have two bad choices:
* fix my package *right now* and hope nobody has used the broken repos in-between, no matter what I've originally planned doing now.
* copy the base packages in a version that works into my project to be safe from such intrusive changes.
If, however, the release is tagged with some api version, then I've pointed to Foo-foo:Release-1.7 or Foo-foo:Stable-1.7 and I'm safe.
Or maybe Foo-foo:API-1.7?
I'm bringing this up because we've had exactly this problem when rails was updated to 2.0 and that broke packages like our obs packages.
S.
Susanne Oberhauser wrote:
Adrian Schröter adrian@suse.de writes:
Yes. This is not a big problem (except for storage), but the question is we want to force the user manually to switch repos on updates.
I think in most cases a :Stable and a :Unstable makes more sense.
Let me try to understand what that means.
So I release some software, Bar-o-meter, 1.0.
I've released and tested Bar-o-meter with some other project Foo-foo, Version 1.7, which is what's currently in Foo-foo:Stable.
Now Foo-foo:Stable is updated to 2.0, which breaks APIs. Now I have two bad choices:
fix my package *right now* and hope nobody has used the broken repos in-between, no matter what I've originally planned doing now.
copy the base packages in a version that works into my project to be safe from such intrusive changes.
If, however, the release is tagged with some api version, then I've pointed to Foo-foo:Release-1.7 or Foo-foo:Stable-1.7 and I'm safe.
Or maybe Foo-foo:API-1.7?
I'm bringing this up because we've had exactly this problem when rails was updated to 2.0 and that broke packages like our obs packages.
If I remember correctly it was vice versa: from some point in time ruby 2.0 was needed, because ruby rails 2.0 features were use in OBS. Still, there were rails 1.x and rails 2.x pkgs present. But: there is some unhappyness with lots if copied/linked instead of "included" packs like python, ruby, etc.
Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Martin Mohring martin.mohring@5etech.eu writes:
If I remember correctly it was vice versa: from some point in time ruby 2.0 was needed, because ruby rails 2.0 features were use in OBS. Still, there were rails 1.x and rails 2.x pkgs present.
Right, but that still illustrates the problem: the new release of OBS needed another API version than the old one. _this_ time, it didn't make sense to have them both around but if we had needed both obs releases around for a period of time we'd needed to make each one 'point' to the right peer.
But: there is some unhappyness with lots if copied/linked instead of "included" packs like python, ruby, etc.
Exactly.
S.
On Monday 16 June 2008 12:29:06 Susanne Oberhauser wrote:
Adrian Schröter adrian@suse.de writes:
Yes. This is not a big problem (except for storage), but the question is we want to force the user manually to switch repos on updates.
I think in most cases a :Stable and a :Unstable makes more sense.
Let me try to understand what that means.
So I release some software, Bar-o-meter, 1.0.
I've released and tested Bar-o-meter with some other project Foo-foo, Version 1.7, which is what's currently in Foo-foo:Stable.
Now Foo-foo:Stable is updated to 2.0, which breaks APIs. Now I have two bad choices:
fix my package *right now* and hope nobody has used the broken repos in-between, no matter what I've originally planned doing now.
copy the base packages in a version that works into my project to be safe from such intrusive changes.
* build old and new ones in Stable project. Since the api breaks, you would anyway need to be able to install the old version beside the new one.
If, however, the release is tagged with some api version, then I've pointed to Foo-foo:Release-1.7 or Foo-foo:Stable-1.7 and I'm safe.
Or maybe Foo-foo:API-1.7?
I'm bringing this up because we've had exactly this problem when rails was updated to 2.0 and that broke packages like our obs packages.
When you add numbers, you enforce all users and packagers to switch manually.
Adrian Schröter adrian@suse.de writes:
- build old and new ones in Stable project. Since the api breaks,
you would anyway need to be able to install the old version beside the new one.
Hmmm... like this, with explicit API version requires and provides in the packages and duplicate packages in the project?
:Good-weather/:Bar-o-meter/bar-o-meter.spec Version: 1.0 Requires: Foo-foo-api = 1.7
:Cooltech/:Foo-foo/Foo-foo-1.7/foo-foo.spec Version: 1.7.3 Provides Foo-foo-api = 1.7
:Cooltech/:Foo-foo/Foo-foo-2.0/foo-foo.spec Version: 2.0.3 Provides Foo-foo-api = 2.0
This could work with the new 11.0 solver, as it takes 'the best' instead of the newest package.
Or will this result in annoying error messages:
Can't update package foo-foo, that would break dependencies.
(*) ignore update of package foo-foo ( ) remove package bar-o-meter
'Freezing' package foo-foo is _not_ an option because it may be very reasonable to provide an update to Foo-foo-1.7, Version: 1.7.4, and _that_ should be installed right away.
When you add numbers, you enforce all users and packagers to switch manually.
For the packagers this would be ok, because as the API breaks the packages need to be touched anyway to get them working on the new API.
For the users, we need an update path from anumber of connected repos to a number of corresponing repos anway, because we need to migrate base products and add-on products (and add-ons hereof):
GA --> SP1 add-on-to-GA --> add-on-to-SP1 (or possibly SP1 obsoletes this add-on)
S.
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
Hi Peter,
Peter Poeml poeml@suse.de writes:
Nitpick: no new python is required. (Just some modules.)
Yes.
For that reason we linked some packages into the current openSUSE:Tools:Unstable project and made them build on the old distros, too.
[This is evil]
Fully agreed, that's why I brought this up.
So simple:
- wait if it actually happens at all
- talk to the maintainers so they are aware
- move on. ;-)
We still could link a package with patches into openSUSE:Tools _then_.
We've already had 1), and 2) is only a solution after the fact and doesn't prevent others from breaking 'my product'.
linking in the package is not the solution I'm proposing, though, it's an ugly work-around that I'd like to avoid.
You and I are members of the obs team, we are used for things to break and we're used to get a quick fix, plus we don't _rely_ on obs yet for some other bread-and-butter business (like releasing a product that uses obs).
Fortunately we start seeing people using obs for such jobs, where obs is a tool that's supposed to work, not the tool that is being worked on.
I'd love to see more of this, a real network of obs instances, and my concern is that by iterating 1) and 2) above, the early birds shy away.
I don't like this proposal. I really don't think that anybody needs different releases of the build service at all.
At this time, this is right. But there is aneed for different Rails releases. So far non of the base python packages were API incompatible after upgrades, so _so far_ we're fine on that end.
Now there's two options:
1) I, as maintainer of some Foo-foo project , need to know exactl the different API policies of the base projects I rely on
2) there's an established policy of giving new APIs a new name, and I just rely on that.
Option 2) implicitely is implemented by the openSUSE releases. after release, they don't change dramatically any more.
I don't think we are going to (nor need to) maintain old releases in "maintenance-mode", we will rather move on.
I'm currently talking about the base packages, and for a foreseeable future I'm also talking about force-updating users with possibly incompatible versions by releasing new packages into the old release repo.
Maybe this is just me but I'd hate to run zypper up and after that the system I just _use_ to build some packages doesn't work any more :/
S.
Susanne Oberhauser wrote:
Hi Peter,
Peter Poeml poeml@suse.de writes:
Nitpick: no new python is required. (Just some modules.)
Yes.
For that reason we linked some packages into the current openSUSE:Tools:Unstable project and made them build on the old distros, too.
[This is evil]
Fully agreed, that's why I brought this up.
The links were only done because:
- there is no other project yet were we can get the required pkgs for all the target distros (also the python pkgs are not yet been there for Fedora) - there are required version updates of packages (e.g. createrepo), which are needed by OBS scripts. - some required sub packages might also been required to update.
So we have the situation that the pkgs are intentionally supplied with new versions atm. What to do with packages that: a) need a newer version in OBS b) have an old version of the package in the distro c) beak on update to the new required version. Tell me how to solve this and I do it.
I was not able to test all the combinations if we implement a policy of keeping old versions if it works and upgrading to new if it doesnt. Who wants to test that?
So simple:
- wait if it actually happens at all
- talk to the maintainers so they are aware
- move on. ;-)
We still could link a package with patches into openSUSE:Tools _then_.
We've already had 1), and 2) is only a solution after the fact and doesn't prevent others from breaking 'my product'.
linking in the package is not the solution I'm proposing, though, it's an ugly work-around that I'd like to avoid.
You and I are members of the obs team, we are used for things to break and we're used to get a quick fix, plus we don't _rely_ on obs yet for some other bread-and-butter business (like releasing a product that uses obs).
Fortunately we start seeing people using obs for such jobs, where obs is a tool that's supposed to work, not the tool that is being worked on.
I'd love to see more of this, a real network of obs instances, and my concern is that by iterating 1) and 2) above, the early birds shy away.
May this was not clear, but I agree with Susanne that we have 1) and 2) already.
I don't like this proposal. I really don't think that anybody needs different releases of the build service at all.
At this time, this is right. But there is aneed for different Rails releases. So far non of the base python packages were API incompatible after upgrades, so _so far_ we're fine on that end.
Now there's two options:
I, as maintainer of some Foo-foo project , need to know exactl the different API policies of the base projects I rely on
there's an established policy of giving new APIs a new name, and I just rely on that.
Option 2) implicitely is implemented by the openSUSE releases. after release, they don't change dramatically any more.
How to do that with multiarch pkgs. They need to comply to all distros policies then.
I don't think we are going to (nor need to) maintain old releases in "maintenance-mode", we will rather move on.
I'm currently talking about the base packages, and for a foreseeable future I'm also talking about force-updating users with possibly incompatible versions by releasing new packages into the old release repo.
Maybe this is just me but I'd hate to run zypper up and after that the system I just _use_ to build some packages doesn't work any more :/
Most OBS users are just users, not developers.
They want fire and forget. Only people that know already that they want to make a challenge (some yet untested feature etc.) look deeper and might install some testing version or even install from source.
Its a fact that we had in the past more than once "released" versions that broke your build service.
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
buildservice@lists.opensuse.org
-
Adrian Schröter -
Martin Mohring -
Peter Poeml -
Susanne Oberhauser -
Vincent Untz