[CentOS] Centos 6.3 - which repos to use?

[Johnny Hughes]

On 01/27/2013 07:18 AM, Bry8 Star wrote:
> Hi Anthony, it would be really great, to see various types of
> repo-configs on centos wiki, now if few helpful & experienced users
> can grab this idea and come forward and share their repo config (and
> their case/usage scenario along with that), then that would be great.
>
> I'm wondering, why no (experienced) users have already done that yet
> ! ? (CentOS is not very new at all).
>
> Boxes where i try/test-out new features, apps, etc, I think my repo
> configs on those will probably be not useful for many & not likened
> by many, as my need & choices & mods are different than others.
>
> Service providing (production) server box's repo configs are
> comparatively & usually much simpler.
>
> i will try to share few of my repo-configs in wiki, these are,
> again, will be based on
> my own choices+cases+scenario+preferences.
>
> So even if i share my own repo-configs, it will not solve problems
> of many types of the mass / users.
>
> Someone already EXPERIENCED in CentOS and long time user, should
> FIRST come forward for the community in WIKI pages, and set an
> example standard, (amazingly no has yet done that), ... whereas i'm
> relatively much less-experienced and recently trying to build boxes
> out of RHEL clone/derivatives (CentOS), with expectation that it
> might be possible to provide service(s) based on already available
> various latest released apps, which are STABLE+last+latest.

Every major 3rd party repository out there already provides a Release
RPM that sets up their repository.  It drops a file in /etc/yum.repos.d/
and the only real thing that one needs to do to those repo files is to
set priorities on them if you want to do that.

The problem with 3rd party repos is that they are not necessarily
designed to work together.  So this means, for example, that EPEL and
RPMForge have conflicts between themselves regarding package versions, etc.

Other 3rd party repos might replace packages in the base CentOS
distroibutions with older ones.

One thing to remember about Linux is that some packages are built
against other packages to share features.  As an example, openssh from
CentOS-6.3 requires the following packages to build against:

gtk2-devel 
libX11-devel 
autoconf 
automake 
perl 
zlib-devel 
audit-libs-devel >= 2.0.5
util-linux 
groff 
man 
pam-devel 
tcp_wrappers-devel 
fipscheck-devel 
openssl-devel >= 0.9.8j
openldap-devel 
krb5-devel 
libedit-devel 
ncurses-devel 
nss-devel 
libselinux-devel >= 1.27.7
audit-libs >= 1.0.8
xauth 

So, if you upgrade the gtk2 to a new version for some new package, then
you would also need to rebuild (or upgrade and rebuild) openssh. 

Taking gtk2 as in our example here, if you wanted a new gtk2 in
CentOS-5.9, then you would have to rebuild the following packages:
 
alacarte-0.10.0-1.fc6.src.rpm
anaconda-11.1.2.259-1.src.rpm
at-spi-1.7.11-3.el5.src.rpm
avahi-0.6.16-10.el5_6.src.rpm
bluez-gnome-0.5-5.fc6.src.rpm
bug-buddy-2.16.0-2.el5.src.rpm
control-center-2.16.0-16.el5.src.rpm
devhelp-0.12-22.el5_8.src.rpm
eclipse-3.2.1-19.el5.centos.src.rpm
eel2-2.16.1-1.el5.src.rpm
ekiga-2.0.2-7.0.2.src.rpm
eog-2.16.0.1-6.el5.src.rpm
esc-1.1.0-13.el5_8.2.src.rpm
evince-0.6.0-17.el5.src.rpm
evolution-2.12.3-19.el5.src.rpm
file-roller-2.16.0-2.fc6.src.rpm
firefox-10.0.11-1.el5.centos.src.rpm
firefox-10.0.12-1.el5.centos.src.rpm
gail-1.9.2-3.el5_4.src.rpm
gcalctool-5.8.25-1.el5.src.rpm
gcc-4.1.2-54.el5.src.rpm
GConf2-2.14.0-9.el5.src.rpm
gconf-editor-2.16.0-3.el5.src.rpm
gdm-2.16.0-59.el5.centos.src.rpm
gedit-2.16.0-9.el5.src.rpm
gftp-2.0.18-3.2.2.src.rpm
ghostscript-8.70-14.el5_8.1.src.rpm
gimp-2.2.13-2.0.10.el5.src.rpm
glade2-2.12.1-6.el5.src.rpm
gnome-applets-2.16.0.1-19.el5.src.rpm
gnome-applet-vm-0.1.2-1.el5.src.rpm
gnome-bluetooth-0.7.0-10.2.el5.src.rpm
gnome-desktop-2.16.0-1.el5.centos.1.src.rpm
gnome-games-2.16.0-2.el5.src.rpm
gnome-keyring-0.6.0-1.fc6.src.rpm
gnome-mag-0.13.1-1.fc6.src.rpm
gnome-media-2.16.1-3.el5.src.rpm
gnome-mount-0.5-3.el5.src.rpm
gnome-netstatus-2.12.0-5.el5.src.rpm
gnome-nettool-2.16.0-1.fc6.src.rpm
gnome-panel-2.16.1-7.el5.src.rpm
gnome-python2-2.16.0-1.fc6.src.rpm
gnome-python2-desktop-2.16.0-3.el5.src.rpm
gnome-python2-extras-2.14.2-7.el5.src.rpm
gnome-screensaver-2.16.1-8.el5_7.5.src.rpm
gnome-session-2.16.0-10.el5.src.rpm
gnome-system-monitor-2.16.0-4.el5.src.rpm
gnome-terminal-2.16.0-5.3.el5_6.1.src.rpm
gnome-themes-2.16.0-1.fc6.src.rpm
gnome-user-share-0.10-6.el5.src.rpm
gnome-utils-2.16.0-5.el5.src.rpm
gstreamer-plugins-good-0.10.9-1.el5_3.2.src.rpm
gthumb-2.7.8-8.el5.src.rpm
gtk2-engines-2.8.0-3.el5.src.rpm
gtkhtml2-2.11.0-3.src.rpm
gtksourceview-1.8.0-1.fc6.src.rpm
gtkspell-2.0.11-2.1.src.rpm
gtk-vnc-0.3.8-3.el5.src.rpm
gucharmap-1.8.0-1.fc6.src.rpm
icon-slicer-0.3-7.2.2.src.rpm
im-chooser-0.3.3-6.el5.src.rpm
jpilot-0.99.8-7.1.src.rpm
kasumi-2.0.1-1.1.fc6.src.rpm
libbonoboui-2.16.0-1.fc6.src.rpm
libbtctl-0.6.0-9.2.el5.src.rpm
libdv-0.104-4.fc6.1.src.rpm
libgail-gnome-1.1.3-1.2.1.src.rpm
libglade2-2.6.0-2.src.rpm
libgnomecanvas-2.14.0-4.1.src.rpm
libgnomeprintui22-2.12.1-6.src.rpm
libgnomeui-2.16.0-5.el5.src.rpm
libgpod-0.4.0-1.el5.src.rpm
libgtk-java-2.8.7-3.el5.src.rpm
libnotify-0.4.2-6.el5.src.rpm
librsvg2-2.16.1-1.el5.src.rpm
libwmf-0.2.8.4-10.2.src.rpm
libwnck-2.16.0-4.fc6.src.rpm
metacity-2.16.0-16.el5.src.rpm
mtr-0.71-3.1.src.rpm
nautilus-2.16.2-10.el5.src.rpm
nautilus-cd-burner-2.16.0-7.el5.src.rpm
nautilus-sendto-1.0.1-6.el5.centos.src.rpm
NetworkManager-0.7.0-13.el5.src.rpm
nmap-4.11-2.src.rpm
notification-daemon-0.3.5-9.el5.src.rpm
notify-python-0.1.0-3.fc6.src.rpm
nspluginwrapper-1.3.0-9.el5.src.rpm
openoffice.org-3.1.1-19.10.el5_8.4.src.rpm
openssh-4.3p2-82.el5.src.rpm
oprofile-0.9.4-20.el5.src.rpm
orca-1.0.0-5.el5.src.rpm
pidgin-2.6.6-11.el5.4.src.rpm
pinentry-0.7.3-3.el5.src.rpm
planner-0.14.1-4.el5.src.rpm
poppler-0.5.4-19.el5.src.rpm
pygtk2-2.10.1-12.el5.src.rpm
redhat-artwork-5.1.0-28.el5.centos.src.rpm
rhythmbox-0.11.6-4.el5.src.rpm
sabayon-2.12.4-9.el5.src.rpm
samba3x-3.6.6-0.129.el5.src.rpm
sane-frontends-1.0.14-1.2.2.src.rpm
scim-1.4.4-44.el5.src.rpm
scim-pinyin-0.5.91-16.el5.src.rpm
scim-tables-0.5.6-7.src.rpm
setools-3.0-3.el5.src.rpm
sound-juicer-2.16.0-3.el5.src.rpm
thunderbird-10.0.11-1.el5.centos.src.rpm
thunderbird-10.0.12-3.el5.centos.src.rpm
trousers-0.3.1-4.el5.src.rpm
tsclient-0.148-6.el5.src.rpm
usermode-1.88-3.el5.2.src.rpm
vim-7.0.109-7.2.el5.src.rpm
vino-2.13.5-9.el5_4.src.rpm
virt-manager-0.6.1-16.el5.src.rpm
virt-viewer-0.0.2-3.el5.src.rpm
vte-0.14.0-2.el5.src.rpm
w3m-0.5.1-18.el5.src.rpm
wireshark-1.0.15-5.el5.src.rpm
xcdroast-0.98a15-12.2.2.src.rpm
xchat-2.6.6-8.el5.src.rpm
xen-3.0.3-142.el5.src.rpm
xsri-2.1.0-10.fc6.src.rpm
xulrunner-10.0.11-1.el5_8.src.rpm
xulrunner-10.0.12-1.el5_9.src.rpm
yelp-2.16.0-29.el5_8.src.rpm
zenity-2.16.0-2.el5.src.rpm

Not only would you need to rebuild all those packages if you upgraded
gtk2 ... you might have to find a newer version of the package because
the current one might not build against the version of gtk2 you upgrades to.

Also, you would now also need to find and build any packages that build
against the packages you just built ... an example here is that a given
version of gnome is tied to a certain range gtk2 and if you wanted to
upgrade gtk2, you might also have to upgrade gnome ... and that would
mean you would also have to upgrade everything that builds against
gnome, etc.

So upgrading one package can cause a domino effect that means you have
either broken a bunch of packages or you have to rebuild a bunch of
packages.

That is why RHEL (and therefore CentOS, as we rebuild their sources)
does not do that.

Enterprise Linux is, by definition, designed to maintain the main APIs
and ABIs that come out at the beginning of the distribution for the
entire lifetime of that main version.  So, CentOS-5 will always have
Gnome 2.16.  Anything that requires a Gnome > 2.16 is likely never going
to be released for CentOS-5.  The point releases are basically just a
point in time "freeze" of the tree to generate install media with
updates ... though new functionality is sometimes added and that also
takes place during the point releases.  But this new functionality is
not going to require a new major version of Gnome/GTK or KDE or httpd or
openssh or openssl, etc. 

Each major version of CentOS is designed to give you its major
functionality that it comes with for 10 years.  It is not designed to be
cutting edge, it is designed to function like it did when you installed
it for 10 years from the time it was released.  That means if you are an
ISP (or Facebook or Zynga) and you invested $1 Million dollars in
writing software, you can know how long your software will be able to
run before you have to invest to rewrite it for a new platform.  You
can't rewrite your software every 6 months when the latest version of
Gnome is released.  You need a solid, stable platform to run your code
for a long time.  That is Enterprise Linux.

Some of the Main versions (CentOS-5 and CentOS-6 and CentOS-7) will be
active at the same time, and you can pick the main tree that provides
the version that you need and you can then stabilize on it.  Right now,
both CentOS-5 (active until 2017) and CentOS-6 (active until 2020) are
both active.  They will both be secure until their EOL dates by a
process that Red Hat calls backporting:

https://access.redhat.com/security/updates/backporting/

If one is looking for the latest and greatest Linux features on the
cutting edge, well CentOS is not for that.  Fedora would be the Red Hat
product that is cutting edge ... or Rawhide if you are looking for
bleeding edge.

Debian has the same sort of thing.  They have oldstable (gets security
updates for 1 year after a stable release), stable (the current
release), testing (the next release), and unstable (cutting edge, named
sid).

Rawhide is like sid, Fedora is like the Testing release, RHEL is like
the Stable Release and the Old Stable release.  Except RHEL (and CentOS
since we build those sources) provides those stable releases for a lot
longer period of time.

Lenny is Debain's Old Stable and it no longer gets security updates ...
but it was active from February 2009 to February 2012.  That is only 3
years.  CentOS is around for 10 years.

With CentOS, you normally get to pick when you need to upgrade based on
your requirements, not an artificial time period of 3 years maximum. 
However, you can, if you want upgrade to a new version of CentOS every
2-3 years as well ... it is just not required to get security updates.

For example, CentOS-4 was released in March 2005 and CentOS-5 was
released in April 2007 CentOS-6 was released in July 2010.  So, the
ability to upgrade (if you want) every couple of years is there as well
as going up to 10 years between upgrades (if you choose to).

My point is that if you are expecting CentOS to be Debian from SID to
OldStable or OpenSUSE or Fedora ... it is not that, nor is it meant to
be that.  It is meant to be a long term stable release.


> For example, IF CentOS/RHEL (based/clone/derivative linux) has a
> specific app/lib at v7.00, and if the source/origin/upstream
> developer has released a STABLE version v9.00 (with new features and
> older bugs fixed), and when more bugs are fixed later on for the
> v9.00, then how that patch/code is re-implemented on v7.00 ! ? would
> not a v9.00 bug-fix/patch cause more problem(s) when applied on v7.00 ?
>
> or, is it this case, that, when a bug-fix/patch is applied on an
> older v7.00 app/lib by RHEL upstream developers (or by origin/source
> upstream developers), and then, that is, later
> re-applied/re-implemented on RHEL/CentOS (clone/derivative) v7.00
> app/lib ?
>
> So, does that mean that a CentOS/RHEL based clone/derivative linux's
> v7.00 app/lib, will always lack new v9.00 features ? until, few
> months/yrs later when CentOS/RHEL clone/derivative also gets finally
> updated to v9.00 ? but by then source/origin upstream developers
> most likely already released v11.00 or so ?
> or, is it this case, that, when some features of v9.00 are
> transferred into v7.0, then that is also re-implemented by
> CentOS/RHEL ? is this really happens ?
> or, is it, that, CentOS/RHEL based linux developers decide to add
> v8.00 in CentOS/RHEL, as an update to the previous v7.00, and then
> that is re-applied over the previous v7.00 ? but is not by then RHEL
> or source/origin upstream/developers already released v10.00, after
> v9.00

Some items on the Desktop (like Firefox, Thunderbird, LibreOffice, etc.)
are upgraded inside a major release, but most things are not going to
be.  If CentOS-5.0 ships with Gnome 2.16 ... Gnome 2.16 is going to be
the version it ends with as well in 10 years (it will get security
updates and may go from 2.16.1 to 2.16.8 or whatever, but it will still
be 2.16.x at the end).

CentOS is not designed to major upgrades in place.   Because CentOS does
not change major ABIs and APIs inside a major release, you can use the
normal tools (like yum) to upgrade between the point releases in a given
major release (that would be CentOS-5.x to any other CentOS-5.x, ie,
upgrade from 5.2 to 5.9 is supported).  However the ABIs and APIs can
have major changes between major releases and therefore your
configuration files and other things (like data, etc) will likely
require changes if you move to a new major version (that would be moving
from a CentOS-5.x release to a CentOS-6.x release).

CentOS is what it is, so please make sure you are using it for what it
is meant for, not trying to make it be one of the cutting edge, release
every 6 months, distros of Lunix ... if that is the kind of Linux you
want then CentOS is not for you.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20130127/bb3f6974/attachment.sig>