On 12/14/2011 11:04 PM, Steve Traylen wrote:
[snip]
>>
>> I do repost my question:  how does one compare the various repositories?
>>
>> Note that EPEL states:
>>
>> Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special
Interest Group that creates, maintains, and manages a high quality set
of additional packages for Enterprise Linux, including, but not limited
to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL).
>>
>> EPEL packages are usually based on their Fedora counterparts and
>> will
never conflict with or replace packages in the base Enterprise Linux
distributions. EPEL uses much of the same infrastructure as Fedora,
including buildsystem, bugzilla instance, updates manager, mirror
manager and more.
>>
>> End quote. Thus, EPEL claims that EPEL packages will never
>> conflict
with or replace packages in the base Enterprise Linux distributions. If
this claim is factual, then one presumably can mix EPEL and SL packages
(for the same release and architecture) without concern. I am attempting
to discover if this sort of a claim is true for any other of the public
repositories.
>>
>
> Take a look here, http://iuscommunity.org/Docs/SafeRepoInitiative
> was
an attempt to define such a safe repository.
>
> Epel and Sl , its almostvtrue but there have been exceptions, e.g Sl
has icewm as an addition but epel just added it in the last week or so.
>
>> Yasha Karant

Having looked over the http://iuscommunity.org/Docs/SafeRepoInitiative, 
this is very close to what I personally want and what is needed for a 
sane approach.

Just as there is a Grand Unified Boot Loader, we need a Grand Unified 
Repository.

Given the ability of current (OO) technology to handle polymorphism and 
inheritance, it should be possible to come up with a naming and both 
execute and ldd path implementation that would prevent the clashes. 
Thus, application X would execute in a different environment than 
application Y.  The only major problem is if a kernel-call is required 
using a kernel library of a higher revision than that of the EL release, 
as these libraries are in some sense intimate to the operation of Linux 
given the monolithic kernel design and implementation.  However, many 
(most?) end-user applications do not require such kernel calls.

Is there any serious effort within the EL community to establish such a 
thing?

What follows is commentary and explanation that those who do not want to 
read a "pontificating professor" should skip.

Here is the fundamental problem from my experience.  The stock EL 
distribution contains many add-on applications that are not up to 
current stable revision version from the application source author(s). 
In many cases, this prevents the stock application from being useful. 
However, the current application may require an environment (e.g., 
libraries) not used in the stock EL distribution.  In some cases, the 
current application version -- if available from source -- can be 
back-ported to the state of EL -- if someone is available to do the work 
and the testing.  Ultimately, everything changes with the advent of EL 
N+1, but such a transition happens at much longer time intervals than 
application major revisions in many cases, and to go from EL N to EL N+1 
requires what amounts to a fresh install -- this update cannot be 
handled as an incremental update as repeatedly has been made clear on 
this list.

For a strict server computer for which major server applications (those 
providing DNS, HTTP, SMTP, etc.) are all that are used, such an approach 
may not be as major an issue for reasons that I can elucidate if there 
is interest.  For those of us who use EL on workstations (including 
laptops) because we want the stability of, say, Mac OS X production -- a 
commercial, supported and debugged system (unlike, say, MS Win 
workstation, commercial for profit, but both poorly supported and poorly 
debugged) -- within the open systems model -- the issue is more 
pressing.  We need to stay current with end-user formats and application 
interoperability, but without the instability of an enthusiast 
distribution.  SL, like that of TUV, has the further significant 
advantage of professional paid (job, not volunteer) developers and support.