Yum repo compatibility

[Michael Schwendt]

On Fri, 5 Nov 2004 18:46:19 +0100 (CET), Dag Wieers wrote:

> > There are a very few people (or maybe it's just one) who don't realize
> > that I'm just a contributor. I'm not in charge of the policies and
> > objectives. I'm not a fedora.us spokesman either. Gah! It's insane to
> > think that, when I never ever claimed to be a spokesman. Fedora.us
> > provides a system which allows community commitment, where I, as a member
> > of the community, can contribute. Other contributors have noticed the
> > possibility, too. On the contrary, when fedora.us was started, and even
> > many months later, no other packaging project was ready to accept
> > community commitment beyond private mails or mailing-lists.
> 
> That's not really correct, Michael. It may be your believe, but the fact 
> that at the start most of the 3rd party packagers were involved in 
> fedora.us is a clear indication that we believed in a single merged 
> repository in the long run.

Some random excerpts and quotes from the old list, roughly in
chronological order:

  Nov 2002 : Axel Thimm wants packages to be vendor independent, while
  Panu Matilainen says that would be beyond his time to test on any other
  distribution than RH

  Nov 20 2002 (Axel Thimm) : Of course only if Matthias is willing to
  expand his one-man-efford to allow inclusion of trusted third party
  effords, but this is how he described rpmforge.net. The next step is to
  have some mechanism for those built packages to enter freshrpms.net.

  Feb 5 2003 : Axel Thimm (AT) suggests Epoch bumps for alpha|beta|rc
  in %version

  Mar  1 2003 : controversies about package naming guidelines

    AT : That is why one needs to solve the coordination problem of
    multiple repositories before merging them.

    Warren Togami (WT) : The only long term maintainable solution for
    Fedora is to simply have MORE packages than all other repositories.
    It was the intent of this project to hopefully unify the various
    independent packagers and forever put an end to incompatibility.

    AT : The second step is to build upon the established
    situation. freshrpms.net is the standard repository (besides Red Hat),
    and that is a fact. Anything else that going in harmony with freshrpms
    is bad. If there are reasons to dislike some of Matthias practices,
    one should invest time in arguing and coming to an agreement, and not
    in a takeover. Matthias and Red Hat _are_ the vendors ... ;)

  Mar 6 2003 : Warren Togami wants Matthias Saou as release manager
  Matthias Saou says he doesn't know whether he's suited for that or not.
  He may be too picky.

  March 2003 : Seemingly endless controversies about package versioning
  and explicit Epochs, package signing,

  Mar 7 2003 : Axel Thimm sums up his goals and forsees flames.
  Message-ID: <20030307101746.GC5882 at puariko.nirvana>

    c) Coming to agreements about general repository guidelines (cerating
    specifications etc).  

    d) Consolidating the repositories into one (involving creating the
    neccessary infratstructure).

    that is also the coarse view on milestones, I would set. I know that
    people want to start at d) and want to get the project rolling at full
    speed, I'd also like to see the perfect specifications and
    systems. But the recent discussions about versioning, security
    infrastructures etc. show that the project should invest more in its
    planning phase, before getting in the executive one.

    IMHO d) depends on Matthias willing to bring his rpms over (better
    said willing to host the rest of ours - would even solve the name and
    domain problem ;). I don't forsee that he will do currently something
    like that, but I never give up hope! ;)

    Anyway copying freshrpms.net has already been stated as a bad idea,
    therefore at least there an interrepository arrangement has to be
    made. Other smaller repositories (O.K., so I am also thinking about
    mine ;) would also like to be considered.

    Therefore I suggest to have a stronger focus on specifications about
    inter-repository coordination. Let us coordinate the repositories to
    such an extend, that one could indeed copy them all together into one.

    That would involve a common agreement on versioning and overlapping
    rpms. I hope that this way more repository owners will be willing
    contribute, as it merely includes a common sense ;). Having the project
    rolling in this mode for some time will enable the packagers to
    establish and learn methods for common "rpm fighting", and give a good
    taste on fedora. Finally the common repository will be only a matter of
    infrastructure. :=)

    I know I will be flamed, try to be gentle on me. ;)

  Mar 11 2003 : Axel and Warren clash, Warren sees large delays in the
  specification process.

  Mar 21 2003 : Dag Wieers joins, active in kernel module packages discussions

  Apr  5 2003 : Epoch controversy continued... (Matthias Saou)
    
    "Oh well, seems like I'm the ony one arguing _against_ introducing
    mandatory epoch fields in all packages... :-("

  Apr 19 2003 : AT

    Currently fedora is creating the nightmare you mention. People
    _expect_ different repositories to be mixable, apt and yum provide
    ways to have different sources, and then you create something
    incompatible to any other repository out there?

    If freshrpms.net is your 'source of inspiration' why do you stab at it
    (and all the other repositories)? Instead of putting so much energy in
    replacing or swallowing freshrpms, you could try to extend
    it. Matthias has signaled to accept patches, if his builds can be
    improved, and he seems to do so. What was so wrong with freshrpms?

    [...]

    When I joined fedora I was excited about having a project to create
    inter-repository coordination and compatibilty rules.

  Apr 19 2003 : Dag explains why he replaces packages in freshrpms

    Well, I decided to 'replace' some of freshrpms packages because I
    didn't have control over the dependencies. (Especially for the
    audio/video packages, this was sometimes a pain) and I couldn't build
    packages against freshrpms when freshrpms wasn't building against mine
    ;))
 
    Summary: my repository is self-contained but still compatible with
    freshrpms.

  Apr 19 2003 : Dag continues with inter-repository library standard
  proposals

  May 2003 : Matthias Saou comments on normal discussion,
  QA work as fedora.us starts, more and more packages appear

  July 2003 : Matthias tries to defend his "single person entity"

  Nov  8 2003 : Hostile words from Axel Thimm. Panu Matilainen
  points out that Axel misunderstood the goals of fedora.us

    Dag Wieers: [...] most 3rd party packagers already had more 
    packages then Fedora currently.



Whoever may be in search of my first comment on the result of many months
worth of discussion, enter the archives around Nov 2003. Older messages
from me are unrelated.

> The real question is, is there an 
> intention now to find some common ground and loose some of the 
> duplication efforts or not.

Well, let's hope so. Fedora Extras will give the opportunity to extend the
package set and also base 3rd party repositories upon it. Then those 3rd
party repos no longer need to provide the same libfoo-1.0 that is in
Fedora Extras already. Repositories which find Fedora Core not bleeding
enough and thus upgrade Fedora Core, will remain a different side of the
story.

> You have to know that of course Fedora is a too limited view (I've 
> repeated that before on the fedora.us mailinglists too). Our packages work 
> for much more than just Fedora and our userbase is therefor much wider 
> than only Fedora and only i386.

I don't mind distribution-independent packages if I don't need to QA or
support them. And if the distribution independence doesn't result in
bloated spec files and/or patches, which are more difficult to
proof-read. I hope that using a source code management system for packages
will avoid that, since it allows forking package development for different
distributions. I would not like to spend any time on testing something
for rh80, a distribution which is not even supported by Fedora Legacy
anymore.
 
> This should also be appealing to Red Hat, since having a wide set of extra 
> tools and packages that also work for RHEL will only help in selling Red 
> Hat in a lot of environments.

I doubt that extra packages alone increase Red Hat's sales. True, there
are some customers, who appreciate some prebuilt extra packages (I've seen
the messages on taroon-list, too). But increased customer demand would
cause Red Hat to become active and support extra software themselves,
e.g. anti-virus solutions.

> Ok, I thought it was a compliment if I said fedora.us is maturing, but if 
> you say it isn't, I'm not going to argue with you. :)

If you did, I would scratch my head and then shake it in disbelief. ;)

-- 
Fedora Core release 2 (Tettnang) - Linux 2.6.9-1.2_FC2
loadavg: 0.01 0.02 0.00