[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)

Thu Aug 2 11:24:44 UTC 2007
Dag Wieers <dag at wieers.com>

On Wed, 1 Aug 2007, Les Mikesell wrote:

> Dag Wieers wrote:
> 
> > > > > I think you are making too much out of name differences for things
> > > > > that
> > > > > can clobber each other and not enough about ways to let the different
> > > > > things co-exist - on the same machines if you want them, or to let
> > > > > users
> > > > > choose which they want.  If two same-named packages can conflict,
> > > > > someone
> > > > > did something wrong and the issue shouldn't be about who did it but
> > > > > how to
> > > > > avoid it.
> > > > I disagree. If I was going to roll my own packages in my own repository
> > > > to
> > > > overrule the OS repositories, tagging my packages would be essential.
> > > But the tags are in an inconvenient position to control anything.  How do
> > > you
> > > ensure that you'll get your copies if any other repo adds a newer release?
> > > Normally you'd want updates to float to the latest.
> > 
> > Correct, you would think Fedora took care of this, right ? But there is no
> > interest for Fedora to take care of that because they want to be the only
> > repository. It is not something they have an incentive for to fix.
> > 
> > That is exactly the problem. The repotag would be a workaround (and a
> > convenient one for users) but the real changes need to be in yum or
> > somewhere else. And Fedora does not care, so RHEL will not have it.
> > 
> > I have warned for this on the Feodra mailinglist years ago. There just is no
> > interest to have the diversity of more than one repository.
> 
> From an end-user viewpoint, I can't see why anyone would want to maintain a
> potentially-conflicting package of something that can be freely distributed
> and keep it in an isolated repository, especially without any mechanism to
> control which will be installed.

Exactly, yum has a shortsighted implementation that does not allow 
control. Smart is much better at this and Smart-knowledge should be a 
requisite to enter this discussion.

A lot of people are brainwashed by the limits of a tool like yum. Smart is 
much better at allowing people to decide what they want.


> Can you explain the reason anyone would want
> to have diversity instead of a single maintainer per package and the same
> packages in all repositories whose policies find them acceptable?

Because one user *wants* to have one version on their production server 
and only wants to update to a newer release when it is exactly the same 
version and only fixes bugs. (stability)

Another user wants to have the latest version on their test server to be 
able to test this latest release for acceptance. (current)

Both needs are perfectly understandable on an Enterprise Linux operating 
system, both could live in a single repository or on multiple repositories 
and people may want to define exactly what policy they want to follow, on 
a per repository bases or on a per package basis.

Smart does allow this !

--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]