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:
- 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?
already.
policies then.
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
Hi Peter,The links were only done because:
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[This is evil]
openSUSE:Tools:Unstable project and made them build on the old
distros, too.
Fully agreed, that's why I brought this up.
- 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?
May this was not clear, but I agree with Susanne that we have 1) and 2)
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.
already.
How to do that with multiarch pkgs. They need to comply to all distros
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.
policies then.
Most OBS users are just users, not developers.
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 :/
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 > |