Fostering Cooperation (was Yum and EXTRAS)

[Michael Schwendt]

On Wed, 08 Jun 2005 16:33:17 +0100, Andy Green wrote:

> |>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. ;)
> 
> What was my alternative interpretation I just jumped from?

The theories "cooperation is impossible" and "resistance is futile".

> Over time, because (base+extras) is the new base, the problems will
> likely reduce, since repos like Dag intend compatability with Fedora base.
> 
> | However, as soon as somebody spends some time on analysing what kind of
> | coordination would be necessary to solve inter-repository mixing problems
> 
> Seems to me RPM should be asked to deal with some or all of these
> problems if possible.
> 
> |>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
> 
> ''So rather than adding other repositories to your apt/yum configuration
> just because Fedora does not have the packages you want, please do the
> following:
> 
> Encourage the independent packager to submit their packages to Fedora
> QA. After package improvement, QA testing and some security
> verification, their package can be in the Fedora tree. The original
> packager gains the support of other Fedora developers, Bugzilla and
> other infrastructure to raise the level of quality and compatibility of
> submitted packages.''
> 
> That was the only way I saw on the page you would work with the
> [previously] "independent packager".  However I note some willingness
> further down in your last mail.

Once again you're reading between the lines, which is kind of becoming a
hopeless case. That paragraph encourages users to do something when they
think something is missing in the repository. It's also a reaction on
complaints of the form "I've had to add repo X to my yum config because I
could not find app Y at fedora.us and then yum update failed". Sure, it
may be true that temporarily repo X is the only one providing app Y. But
some users just need a hint that it might be an idea to contact a package
developer and suggest to team up with a community project like fedora.us,
especially since familiarity with the [new at that time] fedora.us project
was not spread widely. The paragraph does not say "do not add another
repository, do not use the missing application you've elsewhere". It's
really just like "if you appreciate the community effort, this is what
you can do to make it even better".

Users who know what they are doing, don't need hints or inspiration on how
to support a repository. They would contact an independent packager
automatically or post about it on relevant mailing lists. Such users don't
need help with repository mixing problems either, however.
 
> | 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
> 
> Yeah, as I wrote before (base+extras) is the new base.  Again the effect
> is to pull packages from the RPMForge orbit into Extras, which because
> of its "enabled by default" feature and Fedora relationship is likely to
> become the uber-repo that you envisage.

Which is a good thing. 
 
> | 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.
> 
> It's encouraging that "Cooperation is possible" then... but this is new
> information to me.

As long as you can't explain where your "cooperation is impossible"
theory comes from, I cannot comment on this. Then there's still the
question what kind of cooperation do you think of?
 
> |>|>| 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.
> 
> Is there a URL with a canonical list anywhere?

Existing packaging policies/guidelines (see fedoraproject.org wiki) are
not as detailed as would be necessary to guarantee that if two developers
packaged the same software, the results would be equivalent/compatible.

-- 
Fedora Core release 4 (still from Rawhide) - Linux 2.6.11-1.1366_FC4
loadavg: 2.78 2.54 2.18
-------------- 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/ac301f05/attachment-0001.sig>