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

[Michael Schwendt]

On Sun, 14 May 2006 11:45:46 +0200, Thorsten Leemhuis wrote:

> Seems scop said all the important things about the problems with this
> directfb update already so I like to use this opportunity to comment on
> something related.
> 
> Am Samstag, den 13.05.2006, 21:44 +0300 schrieb Ville Skyttä:
> > [...]
> > The packages are built for all repos all the way down to FC-3 (an "EOL"d
> > release).
> > [...]
> 
> This (e.g. pushing a [major] version update to FE4, FE5 and devel at the
> same time) is something I more and more dislike. Even if soname's don't
> change -- every update bears a risk of breaking stuff (especially
> updates to a new [major] version). Yes, often it works without problems,
> but our experience and mails like
> https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00332.html
> show that sometimes things simply break now and then. We should do our
> best to avoid that our users run into such problems.
> 
> That's one of the reasons why I still would like to have a testing repo
> where all (or at least the major package updates) hang out some days
> until they get pushed to the proper repo. And/or a policy (or make it a
> strong suggestion to packagers) that "[major] version updates should be
> build for devel first; builds for stable releases shouldn't be done
> sooner than five days after the devel packages was published".
> 
> Security-updates of course are outside this scope and should of course
> be pushed as fast as possible.
> 
> Just my 2 cent. Other opinions?

It makes upgrades even more complicated. Remember a few things:

1) A regular [updates-]testing repository exposes only some users to
package releases which may or may not become official. This adds another
upgrade path. Do we work around bugs introduced in these updates? Do
enough active users enable such an optional repository, so that it would
become really helpful? I think Fedora Core Test Updates suffer from quite
some desinterest. Lack of feedback--also success reports--about test
updates doesn't help you to decide whether an update is good.

2) Will the build system build against the test updates or only against
official updates in the main repository? In case it builds against test
updates, what do we do if they are broken? And how are test updates pushed
or withdrawn when dependencies have or have not been built against them?
How does an additional repo solve the problem of insufficient
communication about upgrades and rebuilds of complete dependency chains?