Re: Fostering Cooperation (was Yum and EXTRAS)

From: Michael Schwendt (mschwendt.tmp0501.nospam_at_arcor.de)
Date: 06/08/05

  • Next message: Dotan Cohen: "Re: Filled up the filesystem. How?"
    Date: Wed, 8 Jun 2005 14:50:57 +0200
    To: For users of Fedora Core releases <fedora-list@redhat.com>
    
    
    
    

    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.

    
    

    
    

    -- 
    fedora-list mailing list
    fedora-list@redhat.com
    To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
    


  • Next message: Dotan Cohen: "Re: Filled up the filesystem. How?"

    Relevant Pages

    • Re: Fostering Cooperation (was Yum and EXTRAS)
      ... since repos like Dag intend compatability with Fedora base. ... After package improvement, ... repository, do not use the missing application you've elsewhere". ...
      (Fedora)
    • Re: proFTPD?
      ... Setting up Install Process ... Parsing package install arguments ... FC-3 until you install fedoralegacy repository as FC-3 has now gone EOL ... The normal repositories for fedora core/extras no longer exists for FC-3 ...
      (Fedora)
    • Re: An introduction of the new cheerleader...
      ... >> repository contains a new package, ... But when a package of the same software is in a public ... For inter-repository compatibility, it needs global policies which all ... > to Fedora QA to become a Fedora Extras package. ...
      (Fedora)
    • Re: An introduction of the new cheerleader...
      ... > either downgrade or try the next repository (this experience is based ... But when a package of the same software is in a public ... ccrma builds low latency kernels, atrpms build kernels with the v4l ... to Fedora QA to become a Fedora Extras package. ...
      (Fedora)
    • Re: Yum dependency problems after FC3>FC4
      ... > package clamd ... Seems a different repository has a newer version, ... Extras conflict. ... Remove gda-postgres and reinstall it later from Fedora Extras. ...
      (Fedora)