Fedora "backports" repo? (Was Re: PostgreSQL 9 for F14?)
al.dunsmuir at sympatico.ca
Wed Sep 22 13:59:51 UTC 2010
On Wednesday, September 22, 2010, 8:06:12 AM, drag01 wrote:
> On Wed, Sep 22, 2010 at 11:24 AM, Richard W.M. Jones <rjones at redhat.com> wrote:
>> On Mon, Sep 20, 2010 at 09:58:53PM -0400, Arthur Pemberton wrote:
>>> 2010/9/20 Michał Piotrowski <mkkp4x4 at gmail.com>:
>>> > 2010/9/21 Toshio Kuratomi <a.badger at gmail.com>:
>>> >> As the concept of using third party repositories (both as packagers and as
>>> >> users) grows, this interdependence will grow.
>>> > Ok, so maybe it's time to setup Fedora "backports" repo for these that
>>> > wants new and shiny Firefox 4, PostgreSQL 9 or whatever with big
>>> > number.
>>> What exactly is the fear here with these updates? Are there many
>>> desktop users who do NOT want the latest released Firefox? Are there
>>> many people using Fedora as their OS for their database server?
>> Maybe we should turn this around and ask why more people don't
>> use Rawhide.
> Well "use rawhide" for anything else than testing and/or developing
> the new release just do not fly.
> Some of the reasons I can think of:
> 1) To high rate of changes / breakage
These are two separate issues.
Without change in Fedora, we might as well turn off the lights.
Keeping the change rate high in Rawhide is the whole point. After all,
we are trying to keep the other releases more stable by minimizing
unnecessary or incompatible changes there - E.G. the branched release
that is being packaged, stabilized and validated for formal release,
and especially the stable releases that folks need for normal
The problem you are describing in rawhide is partly due to your other
"Np Frozen Rawhide" was introduced to try to make it so that given a
functional Rawhide, the branching off of a new periodic release would
One issue is that while the other releases have a base, updates and
updates testing repository that is supposed to allow change to be
introduced in a controlled manner, rawhide is basically the other side
of the wall (as in, "throw the update over the wall" after it builds).
This means rawhide tends to be broken because of incomplete or
untested changes, rather than change in general.
If a second rawhide-specific staging repository (equivalent to
updates-testing, so call it rawhide-testing) was added with some
autoqa automation to prevent gratuitous problems (such as broken
dependencies in core components), I suspect the situation would
Migration of updated packages from rawhide-testing to rawhide would be
controlled by the same koji mechanisms that control updating of the
other fedora release, but with less restrictions (some wait by
default, but not a week), support for karma (negative karma to require
override to migrate). I suspect that proventester approval would
not be required (aside from there not being enough proventesters to
also handle rawhide).
> 2) No signed packages
There has been discussion of the signing to be there, marking the
package as being built by the Fedora buildsystem.
> 3) Slower kernel
On purpose - first you get things right, then you get them fast. Those
additional checks are important so that any issues are identified as
soon as possible.
You want to benchmark something? Build a no-debug kernel.
> 4) To much of "manual fixing" required
Maybe reduced with a bit of focus, but likely also part of the nature
of the beast.
> 5) To many broken deps, which might prevent applying updates and security fixes
This one autoqa should be able to solve. Reduces breakage in general,
and helps ensure that breakage in branched releases is identified
> 6) Some others that I can't think of right now might be a consequence
> of the above or something else
Stuff happens, but Rawhide is the place for it to happen. But not
gratuitously - that's not being nice to your fellow Fedora team
> So please stop proposing rawhide for productive systems (or even
> database servers *shrug*).
I think that Rawhide is being proposed for testing those types of
systems, so that folks help ensure new features reach branched
releases ASAP... and in some cases, that might mean an exception
granted to update a stable release.
Anyone using Rawhide for actual production either knows exactly what
they are doing, and is cherry-picking updates once they are done
initial setup... or is irretrievably insane (in which case, they won't
listen to any advise other than the voices in their heads).
More information about the devel