[CentOS-devel] Looking for input from EPEL

Wed Sep 1 16:04:46 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

On 9/1/2010 9:33 AM, R P Herrold wrote:
>
>> The mere fact that Stephen asked here is the proof that EPEL DOES care
>> about other repos. I also would like to point to Kevin's message (
>> https://www.redhat.com/archives/epel-devel-list/2010-August/msg00158.html )
>> which also proves that EPEL does try to avoid creating interoperability
>> problems [*]
>
>> Please, let's focus on technical issues and not restart an useless flame
>> war.
>
> The elided [*] comment tosses some fuel toward the ignition
> source, no?  One swallow does not a Spring, make
>
> It is a fair question -- dist tags / repotags were kept out by
> the efforts of some with @redhat emails.  Has that changed?

It's not so much a flame as an observation that package managers don't 
and can't work with uncoordinated changes in the same namespace.  And 
repotags don't do much to help unless the package manager uses them - 
although they do help in diagnosing problems after they've happened.

> There is a long tradition of differing level of
> interoperability. Sadly, although one might wish that any
> archive can interoperate with any archive, and that one never
> 'steps' on another archive, that can can never come to pass,
> for reasons noted in my post a couple years back to the EPEL
> ML

I'm not convinced.  I've got plenty of disk space.  If you are going to 
modify a stock library, name it something else and name the package it's 
in something else - and make the things that need your non-stock changes 
use your copy instead.  Do the same things you'd do with it if you were 
developing and testing a modified version on your own machine while 
keeping the stock version in place and running.  This also allows the 
scenario where different users on the same machine want to run packages 
from different repos.

> The obvious means of maximizing portibility and NOT stepping
> on another archive, is simply building packages that depend
> ONLY on LSB provided interfaces, and uses a private namespace,
> assigned by LANANA   that approach exists, has existed, and
> still work today.  It is merely cumbersome -- so automate it!!

I'm not convinced there either.  Even if you follow LSB guidelines, 
uncoordinated packagers are going to step on each others' choices in 
compile options, config file layout.

> I'll just point at LSB, and say:
>   	It is there for a reason

Does one or the other of the epel and rpmforge copies of viewvc violate 
lsb?  If an update flips from one to the other your setup is broken - 
and it doesn't even involve dependencies.

-- 
    Les Mikesell
      lesmikesell at gmail.com