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.
