package updates for in all repos at the same time (Was: Incoming: directfb soname problems)

[Thorsten Leemhuis]

Am Sonntag, den 14.05.2006, 20:09 +0200 schrieb Michael Schwendt:
> On Sun, 14 May 2006 17:21:00 +0200, Thorsten Leemhuis wrote:
> 
> > But we simply could use the current scheme
> > until then: packages foo1 and foo2 are build and a particular point in
> > time and pushed to the testing repo together and another point of time.
> > bar1 and bar2 get build some days later and also pushed to testing
> > together. Five days after foo1 and foo2 were pushed both pacakgers are
> > moved from testing to the proper repo. bar1 and bar2 would follow
> > together five days after their push.
> 
> foo1 and foo2 break dependencies in extras-testing. :)

You mean as a example? Okay.

> Let's assume extras-testing is covered by a repoclosure report.

It of course should.

> Still,
> only after 2-3 days a real user gets nervous and reports the breakage.  A
> day later another packager, who receives the reports, rebuilds his
> packages bar1 and bar2 to fix the broken deps and pushes the builds into
> extras-testing. So, how do you forward the entire set into extras finally?

Well, that a case where manual interaction might be required for now.
But it's still better then now where the breakage would immediately
would have hit the proper repo. 

> If it's done automatically, foo1 and foo2 are pushed several days before
> bar1 and bar2. (yes, it needs somebody to push all four packages at once,
> something that has failed several times before for Core, btw)
> (Or Possibly you want to resolve all deps automatically, but
> in that case it might happen that foo1 is 7 days old, while baz2 has
> just been built, and then you might wait to give the set some longer
> testing)

Still a lot better than the current situation.

> Conclusively, what we need to shield our users from broken updates 

You seem to always center around broken updates with deps -- I mainly
think about new version from upstream or newly introduced bugs in out
packages that are buggy in general or on Fedora. 

> is more
> careful packagers, more communication and coordination of upgrades which
> affect dependencies, and convenient access to a scratch target in the
> buildsys, so not every packager must set up mock and local mirrors of
> multiple distribution releases. And of course guidelines and hints on how
> to avoid common upgrade mistakes (like SONAME changes).

Sure.

> > >  So, Extras packagers must watch another moving target?
> > What do they have to watch precisely? I only seem problems when some
> > packages are pushed directly to the repo. That should only happen for
> > security issues -- we IMHo should be able to handle that.
> 
> As soon as any package, which has dependencies in Extras (whether at
> build-time or run-time, doesn't matter), is pushed into extras-testing,
> the affected Extras packagers must do their own preparations and testing
> against the new stuff in _extras-testing_. And unfortunately, they have
> the choice between two build targets now, "extras" and "extras-testing",
> which gets particularly funny when security fixes join the show.

No. Fifo into testing for *all packages* except security fixes. No build
target "extras". I never proposed that. And that's the point where we
missunderstood each other afaics. 

> I smell chaos and extra burden.

Yeah, that would be correct if we would have a build target "extras" --
but that's not what I propose.

It might make a bit chaos when security updates get to the extras repo
directly. But that's IMHO a acceptable and not that big problem.

> Think fedora.us unstable/testing/stable.  [...]

Yeah, that really wasn't that ideal. 

CU
thl
-- 
Thorsten Leemhuis <fedora at leemhuis.info>