RFE: fedora.us should drop one-repo policy (was: Yum repo compatibility)

[Axel Thimm]

On Fri, Nov 05, 2004 at 11:46:57AM +0100, Michael Schwendt wrote:
> On Fri, 5 Nov 2004 01:40:06 +0100 (CET), Dag Wieers wrote:
> > Let me add to this that the incompatability of the 3rd party
> > repositories has nothing to do with the inability or unwillingness
> > of the 3rd party packagers (to the contrary). But the
> > unwillingness (and policy) of fedora.us to not allow for
> > compatibility. Apparently it is too hard to work with the
> > community.
> 
> "If it's not in bugzilla, it's not a bug."

It is not a bug, it is a feature of fedora.us:

"The Fedora Linux project has made a decision that we will NOT
 cooperate with other repositories due to maintain cross-repository
 compatibilty because it is unmaintainable for several reasons:"

(originally quoted from the wiki, it was deleted from the wiki
database the last time I quoted it ...)

> For instance, in bugzilla.fedora.us I've yet to see bug reports from
> package developers about repository conflicts which are deemed solvable.

So why file a bug against a charter? It's like filing a bug against
lkml for not running on Windows ...

> And let me add to this discussion, that 3rd party repositories which
> upgrade Fedora Core, are an unsolvable source of repository
> conflicts.

You always manage to forget the fedora.us patches, and I had to remind
you on fedora-de only a couple of months ago (together with the wiki
editing/censoring it makes a very funny picture of history revisionism
...)

fedora.us does replace packages on RH8.0-FC1 including critical ones
like libsafe or shadow-utils (or also rpm, gftp, gpg &
friends). Don't be selective in your memory and arguments, please.

(and before anyone misinterpretes this: these replacements may be
for the best of the end-users, just like other third party repos do)

> Not RPM-style file conflicts, but dependency conflicts. If they
> split their packages into Extras and Alternatives, that would be a
> first step in the right direction.
> 
> Btw, fedora.us is the only repository which has package naming guidelines
> and other policies published.

You mean the guidelines that were crafted together with the other
repos and which the other repos abandoned when simple fixes had to be
made to make it multi-repo compatible (the same fixes missing today
for fedora.us <-> livna compatibility, e.g. livna always wins?)

Please, Michael, there are only very few hard core "there can only be
fedora.us" people left, since history has tought otherwise (the ever
greatest compatibility issue was fedora.us' _untested_ epoch-0
slamming, not any inter-repo incompatibility).

You always manage to stir up the wall between fedora.us and the rest
of the world again. Why? You (inadvertently, of course ...) create an
impression of a fedora.us spokesman and people reading your posts
think that all of the fedora.us developers have the same Highlander
attitude like you do. Step back for a while and watch the others do
some _constructive_ integration, will you?

(oh, I forgot, last time I uncovered some wrong statements/lies from
you, you placed me in your killfile [1], so I don't really expect and
answer ...)

And to whoever from fedora.us is really interested in extending the
package universe, please consider ignoring Michael's attitude and try
to cooperate with the other repos. This failed in the final
composition of fedora.us last year, but hopefully the current set of
fedora.us members is more open now (They certainly are, whether the
weight is enough for a change of charter is unkown).

Well, in case this is a vote, I place my vote for fedora.us dropping
the non-mixing policy. This implies a change of naming guidelines.

[1] http://www.redhat.com/archives/fedora-de-list/2004-May/msg00106.html
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20041105/73792e24/attachment-0002.bin