Mailinglist Archive: opensuse-buildservice (261 mails)

< Previous Next >
Re: [opensuse-buildservice] project dependencies
  • From: Martin Mohring <martin.mohring@xxxxxxxxx>
  • Date: Thu, 19 Jun 2008 11:06:10 +0200
  • Message-id: <485A2182.7080302@xxxxxxxxx>
Susanne Oberhauser wrote:
Hi Peter,

Peter Poeml <poeml@xxxxxxx> 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:
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_.


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:

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.

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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >