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.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
