Yum and EXTRAS

[Michael Schwendt]

On Wed, 01 Jun 2005 21:53:28 +0100, Andy Green wrote:

> |>| Packages in Fedora Extras are built with the knowledge that third
> |>| parties will be wanting to provide things like MP3 support (and indeed
> |>| that users demand it), so it's likely that livna (which has historically
> |>| been compatible with fedora.us/Extras) will fill that gap
> nicely.>>Seems strange that it was not possible to cooperate with Dag,
> |
> | ?? Do you refer to Dag's not so friendly paragraph in his FAQ?  Or is your
> | message based on any other sources? We have June 2005, and I'm tired of
> | hearing such complaints. Feel free to travel back in time and dig deep in
> | the various list archives. Feasible solutions have never been found.
> 
> I don't have a horse in this race, but since you ask:
> 
> http://www.fedora.us/wiki/RepositoryMixingProblems

A very old page. But doesn't matter.

> ''Coordination among two or more repositories for compatibility would be
> far too difficult and incur much greater overhead. Updates would often
> involve multiple repository owners working in coordinated development
> and simultaneous publishing in order to prevent user breakage. This is a
> huge amount of extra development overhead.''

That is correct. Do you think it's wrong? If so, why?

> However the RPMforge folks appear to be four repos cooperating.

No. Four people. Each of them runs an own repository, originally with
overlapping and conflicting content. What they are working on is
eliminating the overlapping content, so packager A's package Foo is also
used in packager B's repository, and keeping packages in a common
subversion repository. Effectively, this is half way on the road to
working together on the same repository as if it were a project like
Fedora Extras, except that so far they continue to run their own
repositories, even with their own "brands" (vendor tags like .fr).
Due to that there are still packages which upgrade eachother, though,
e.g. libsndfile-1.0.11-1.1.fc3.fr.i386.rpm (at freshrpms.net)
libsndfile-1.0.11-1.1.fc3.rf.i386.rpm (at Dag's).

Now with regard to cooperation, what is written in above paragraph is very
true, particularly if you keep scalability in mind (number of developers,
number of packages and number of inter-package dependencies). The problem
of cooperation gets worse if you try to increase the number of separately
controlled repositories, which shall depend on eachother or depend on the
same base packages.

> ''Please help Fedora to have all possible packages, these problems can
> one day be a thing of the past.''
> 
> Well, "Fedora" cannot have "all possible packages" due to restrictions
> on which packages Redhat will countenance.  Therefore third party repos
> are brought into being by the distinction between what Redhat can ship
> and what they decide not to.  So the problems will be ongoing.

The phrase "all _possible_ packages" excludes the _impossible_ packages,
of course. ;)

> |>which has
> |>provided many fine and high quality packages to me in the past, but it
> |>is possible to find harmony with Livna.  The effect is that Livna is
> |>anointed by Redhat one-step-removed as the slightly Official vendor of
> |>Forbidden Fruit when they provide Extras .repo enabled by default...
> |
> | No, that is not true. Fedora Extras is part of the Fedora Project. Any 3rd
> | party repository like rpm.livna.org may choose to build upon Fedora Extras
> | and Fedora Core and extend the set of packages.
> 
> "The effect is" being key, not that livna is part of Extras but that it
> is externally associated as a place to get compatible packages.

Any other 3rd party package provider can do the same and choose to supply
the community with packages, which are compatible with Fedora Core and
Fedora Extras and don't replace/upgrade packages in Core or Extras.
 
> Historically Dag's stuff was more than a pimple on Fedora just providing
> Forbidden Fruit.  As a user I don't think it is good if Dag/RPMForge is
> pushed out by an anointed Extras and it would be great if there was
> better feeling between the two camps showing that this is not going to
> happen.  (The idea in the link above that the solution to multiple repos
> is that there should only be one uber-repo, and that other guys should
> "submit" packages for inclusion in the uber-repo is unfortunate).

What makes it "unfortunate"?

Have you ever before thought about how exactly collaboration between
multiple repositories could work? If so, care to share some thoughts?