Fostering Cooperation (was Yum and EXTRAS)

[Michael Schwendt]

On Wed, 08 Jun 2005 12:05:00 +0100, Andy Green wrote:

> |>|>(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"?
> |>
> |>It comes over like a land-grab.  "Cooperation is
> |>impossible"/submit/resistance is futile does not help.
> |
> | Reading between the lines is counter-productive and is one source of
> | misunderstandings. The page does not claim that cooperation would be
> | "impossible". You quoted a paragraph yourself, which explains where
> | fundamental problems are seen. The bottom of the page also comments on
> | users' preferences, such as the desire to get as many add-ons as possible
> | from a single place.
> 
> I don't know how to read that page except as a statement that you will
> not be cooperating with other repos

Now you're jumping back and forth between different interpretations of the
page. ;)

The page is short and to the point in explaining why repository mixing
problems exist and why fedora.us -- the collective of the developers at
the old project -- cannot guarantee that all packages in the repository
are fully compatible with other repositories.

Further, let me emphasise that with regard to individual packages there is
no "you", but only _individual project contributors_, who have the freedom
to decide on their own whether to collaborate and coordinate their
packaging with whoever they want to.  There is no rule, no policy
whatsoever that collaboration would not be permitted, never attempted or
won't ever be done.

However, as soon as somebody spends some time on analysing what kind of
coordination would be necessary to solve inter-repository mixing problems
(even if there is no plan to create inter-repository dependencies),
everything leads back to the rough explanation at the top of the Wiki
page quoted from earlier. Taking care of one repository is enough already
for the majority of contributors.

What may work for an individual (e.g. the overhead of private mail or
chat-based coordination with a 3rd party package provider) may not be a
feasible or acceptable solution for other packagers. It might be
considered as too limiting.

> unless they "submit" packages to you. 

I fail to find that on the page.  The bottom part of the page suggests
that users of independent package providers should encourage them to join
Fedora Extras. The package universe consists of more than a few big and
"famous" repositories. There are many tiny repositories, some yum-enabled,
some not. Many FOSS projects offer distribution specific packages created
and built by project contributors. For many applications not included in
Fedora Core, it would be beneficial, if Fedora packages and their
dependencies were offered as part of Fedora Extras instead of manual
downloads on some FTP/HTTP space.

> Therefore summarizing it that "cooperation is impossible" seems
> fair. 

No, it doesn't do the Wiki page justice.

> If you are saying cooperation with Dag is in fact possible, great!

Well, while you distinguish between "possible" and "impossible", I focus
on what is doable and what is not seen as a hindrance by project
contributors. But let me ask: what kind of cooperation?

The most basic cooperation between multiple repositories would be to
eliminate over-lapping content. That is, replicate common packages between
all repositories participating in the cooperation, so package "foo" is the
same (exactly the same!) in all repositories which provide it. It can
be seen easily how much overhead this would create for N>1 package
developers at Fedora Extras trying to coordinate upgrades/changes with 1
external repository maintainer.

The infamous overhead is there unless common packaging guidelines are
accepted officially and are specific enough as to cover also low-level
spec file details.

In case you monitored fedora-extras-list a bit, you won't find a single
package review, where a reviewer checked Dag's repository to see whether a
package exists already and how it was packaged (package name, feature set,
version, configuration, number of sub-packages, FC integration, ...).
Effectively, verification of compatibility with 3rd party repositories is
not done.  Fedora Extras is treated as _the_ primary base repository after
Fedora Core, which can be built upon. It is focused on these two. External
package providers are welcome to offer add-ons on top of Core+Extras. And
in case an external repository, which depends on Core+Extras, needs
software versions newer than what is provided in Extras, that would be a
scenario for coordination attempts with focus on not breaking Extras. A
way of "upgrade first, then deal with the wreckage" is not something
anyone at Fedora Extras will like.

> |>| Have you ever before thought about how exactly collaboration between
> |>| multiple repositories could work? If so, care to share some thoughts?
> |>
> |>Yeah.  Have you thought about extending RPM?
> |
> | An extended/enhanced RPM is _not_ something we have at the moment. It's
> | not something that was available when Fedora at fedora.us was discussed.
> | It's not ready. Hence it doesn't solve any problem. It doesn't remove the
> | need for fine-grained packaging policies either, which extend up to the
> | spec-file level.
> 
> What kind of policies are we talking about here?  Since everyone at
> least agrees to be compatible with Fedora base, maybe these problems too
> are open to a technical solution.

Policies about everything that would ensure that package "foo" in
repository X is fully compatible with repository Y.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050608/8d3cb581/attachment-0001.sig>