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.
Attachment:
pgp8y9K1m2hkB.pgp
Description: PGP signature
