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

[Les Mikesell]

Dag Wieers wrote:

>>> I cannot see how it is possible to install both the stable package and
>>> current package.
>> How many kernel packages do you have installed?  All it takes is to not write
>> the same-named file in the same place as the other package.  In some cases
>> there are practical problems where a service needs to listen on a default port
>> and you can't run 2 at once, or the init script is expected to live in a
>> certain place so we'd need a creative solution, but most files could just have
>> their own unique path and you'd pick the one you want with your PATH setting -
>> something well understood decades ago.
> 
> RPM allows it, but for anything else the depsolver needs to be modified to 
> allow it. And even if you allow it, there is no policy of what needs to be 
> updated and how. For the kernel there is a lot of specialized logic to 
> make it work.
> 
> While I agree with you that it is possible (in RPM) and can be useful, I 
> do not agree that it is a solution to the repository mixing problem.

It is the solution for cases where there are known differences in 
packages and only the end user/admin can make the right choice about 
which or how many of them he wants.  That obviously can't be automated, 
although I've always wanted to see a way to track exactly the 
package/versions that one system has installed and reproduce it on any 
number of other systems.  In that scenario, an expert sysadmin could 
hand-tune a system for a certain set of functions, publish his 
configuration, and any number of other people could have equally well 
tuned systems that duplicated the setup and tracked the same updates. 
The end user would then have to choose nothing but his virtual 
representative sysadmin.

You'll have to remind me why anyone wants different same-named packages 
with differences the end user doesn't understand and can't control to 
exist at all before I can comment on a solution about managing them.


>>>> 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.

What value does diversity add when the end user can't select which one 
he wants or load all of them?  I understand the scenario where a single 
repository has a policy that prohibits certain packages from being 
included, but the only conflicts in those cases should be where an 
incomplete version is packaged in one place under the same name as the 
full version in a place with a different policy.  The more common case 
would just be additional packages or packages with different names.

 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. 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?

-- 
   Les Mikesell
    lesmikesell at gmail.com