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

Thorsten Leemhuis fedora at leemhuis.info
Sun May 14 11:50:13 UTC 2006


Am Sonntag, den 14.05.2006, 13:13 +0200 schrieb Michael Schwendt:
> On Sun, 14 May 2006 11:45:46 +0200, Thorsten Leemhuis wrote:
> > 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.

Yes, I know.

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

What kind of bugs do you mean exactly? How does core handle it?

> Do
> enough active users enable such an optional repository, so that it would
> become really helpful? 

That's always problematic. But that's not a reason not to do it. It IMHO
would be helpful enough if only all the Extras packagers would enable it
and test their own packages falling out plague. (they can do that with
the needsign-repo, too, but I doubt that a lot of people do that)

> I think Fedora Core Test Updates suffer from quite
> some desinterest.

Well, it's not perfect, but I think it works good enough. 

>  Lack of feedback--also success reports--about test
> updates doesn't help you to decide whether an update is good.

Well, currently there is no testing or decision if a update is good at
all (besides the checking from the packager himself). As a ordinary user
I'd much more prefer a package that was in extras-testing for some days
(without feedback) over one that got no testing at all.

> 2) Will the build system build against the test updates or only against
> official updates in the main repository?

That's the biggest problem.

>  In case it builds against test
> updates, what do we do if they are broken?

The same what we do now when a broken package hits the repo. 

And to make it sure (in case it wasn't already): No, I don't want a
explicit testing repo where stuff could be published and tested that is
not ready yet. I only want a testing repo where all updates hang out
some days before they hit the proper repo. First in and First out (if
there is no major breakage).

>  And how are test updates pushed

Fifo. Example: Package foo is pushed to testing today (Sunday) and bar
on Monday. foo will be pushed to the proper repo on Friday and bar on
Saturday.

> or withdrawn when dependencies have or have not been built against them?

good question. But that shouldn't normally be the case. 

Another example (in case a problem showed up): Package foo is pushed to
testing today (Sunday) and bar on Monday (bar depends on the new foo).
foo makes problems. foo is fixed quickly on Tuesday. foo and bar get
pushed to the proper repo on Saturday.

> How does an additional repo solve the problem of insufficient
> communication about upgrades and rebuilds of complete dependency chains?

Not at all. That's not it's purpose. /me feels misunderstood 

CU
thl

/me sometimes doesn't understand the Open-Source-World -- a lot of
people (see the achieves of the fedora mailinglists) scream when Fedora
Core updates a package directly without letting it linger around in
updates-testing for some days. But proposing the same concept for Extras
only get criticism. Why should Extras be different? *Especially* because
Extras has major version updates that are avoided in Core. 
-- 
Thorsten Leemhuis <fedora at leemhuis.info>




More information about the fedora-extras-list mailing list