Fedora Extras vs. CLOSED RAWHIDE

Ralf Corsepius rc040203 at freenet.de
Tue Aug 3 15:12:10 UTC 2004


Another more political issue in Fedora Core and Extras interaction that
probably needs to be addressed/discussed, probably closely related to
Michael Tiemanns "drafts":

Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of
releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and
leave them as "known bugs" for the current FC-release.

In the end, this results into bugs remaining unaddressed in older
releases (e.g. FC1), while they are fixed in upstream releases (e.g.

In some cases such "known bugs" have an impact on Fedora Extras (Bug
fixed in FC2, present in FC1).

Some examples:

* In some cases such "known bugs" prevent Fedora Extras to supply
packages for downstream releases, because the officially released
packages the Fedora Extras packages are based on are broken.

E.g. "missing shared libs in ghostview"
break gsview for FC1

and "nonfunctional freeglut stub" in FC1 
renders it almost impossible to ship any glut based package for FC1 in

* Sometimes such "known bugs" require Fedora Extras packagers to apply
work-arounds to be able to support downstream distributions.

E.g. the bison.rpm from FC1 lacks a dependency on m4:
which causes packagers to resort to  either resort to build-require
"bison m4" or "byacc" instead of "bison".

Question: How shall this kind of problems be dealt with?

IMO, it would be best if RH/FC would prefer not to close bugs as "CLOSED
RAWHIDE" when ever reasonable/applicable and to officially upgrade the
package instead. 
Alternatively, it could also be worth to consider handing over such a
package to "Fedora Extra" for "interim band-aid packages".

Note: I am not talking about RH to provide general "upstream" updates,
nor I am talking about "Fedora Legacy" or "Fedora Alternaives".
I am only referring to cases where RH's current update policy
blocks/handicaps/limits usability of a release, because someone had
decided a bug fix would not be relevant for public release.


More information about the fedora-devel-list mailing list