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

[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. :)

Let's assume extras-testing is covered by a repoclosure report. 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?
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)

Conclusively, what we need to shield our users from broken updates 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).

> >  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.

I smell chaos and extra burden.

Think fedora.us unstable/testing/stable. At first we liked it, and
possibly considered the classification of new packages as helpful. It was
less easy for version upgrades, cvs snapshots and added packages to reduce
the total number of installable/usable packages in the main repository
through breakage. And we had to fill the repository with more and more
packages without being confronted with breakage too often. But what has
happened later? At least "testing" became quite crowded and made it more
difficult to concentrate on the packages we wanted to see in use by our
users. To decide whether test packages were good enough, developers and
users needed to run "stable" and "testing", getting the entire mix of
packages. And that is ugly. At the current pace updates are pushed out at
Fedora Extras, extras-testing would be filled with packages constantly.