I think Jim (the other one) is doing a marvellous job with extras and plus but he needs to expand the size of his tent. A sensible package policy in extras/plus repo will mean fewer temptations to install 3rd party repo's that can break your system. Some of the packages i would like to see are :-
- MySQL 5 rpms - php 5 rpms (already provided) - Open Office 2.0 rpms - webmin - rkhunter - chkrootkit - tripwire - Adobe, Realplayer & Java plugins (though licensing might be a hindrance) - wine from winehq
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
For a minute there, I thought a generic Vi4gr4 ad had slipped in...
8-)
--- Chris Mauritz chrism@imntv.com wrote:
For a minute there, I thought a generic Vi4gr4 ad had slipped in...
8-)
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Muhaha haha, nah we don't do anything other than CentOS here. :)
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sat, 2006-03-11 at 05:57 -0800, Jim Smith wrote:
I think Jim (the other one) is doing a marvellous job with extras and plus but he needs to expand the size of his tent. A sensible package policy in extras/plus repo will mean fewer temptations to install 3rd party repo's that can break your system. Some of the packages i would like to see are :-
- MySQL 5 rpms
- php 5 rpms (already provided)
- Open Office 2.0 rpms
- webmin
- rkhunter
- chkrootkit
- tripwire
- Adobe, Realplayer & Java plugins (though licensing might be a
hindrance)
- wine from winehq
---- My opinion is that you can trust dag repository which means that you can pick up webmin from there.
Licensing issues mean that you are very unlikely to see Acrobat Reader, RealPlayer or Java in 3rd party repositories
I'll let others comment about the rest.
I will say though that so far, I am really thrilled with kde-redhat repository and they have kept samba up and kde up to date and they have worked really well so far - thanks Rex
Craig
On Sat, 2006-03-11 at 05:57 -0800, Jim Smith wrote:
I think Jim (the other one) is doing a marvellous job with extras and plus but he needs to expand the size of his tent. A sensible package policy in extras/plus repo will mean fewer temptations to install 3rd party repo's that can break your system. Some of the packages i would like to see are :-
firstly, we work in conjuction with dag, dries, and kbs-CentOS-xxxx
The only things that are already in there which go into our extras will be things that they don't have (or things we need to use from there to complete our dependencies).
- MySQL 5 rpms
(already in our testing repo)
- php 5 rpms (already provided)
- Open Office 2.0 rpms
(this is too hard to build and requires things we don't want to install on CentOS build machines ... but the OpenOffice website has RPMS that work OK)
- webmin
- rkhunter
- chkrootkit
- tripwire
(all or most of these are in dag)
- Adobe, Realplayer & Java plugins (though licensing might be a
hindrance)
(as Craig pointed out, we can't due to licensing issues, we also can't provide mp3 stuff)
- wine from winehq
{In KBS extras)
Using 3rd party repos is not bad, they just have to be used wisely with the tools that yum already provides. (includepkgs, exclude, enable ... and/or the protectbase plugin)
On Sat, 2006-03-11 at 08:54 -0600, Johnny Hughes wrote:
On Sat, 2006-03-11 at 05:57 -0800, Jim Smith wrote:
I think Jim (the other one) is doing a marvellous job with extras and plus but he needs to expand the size of his tent. A sensible package policy in extras/plus repo will mean fewer temptations to install 3rd party repo's that can break your system. Some of the packages i would like to see are :-
firstly, we work in conjuction with dag, dries, and kbs-CentOS-xxxx
The only things that are already in there which go into our extras will be things that they don't have (or things we need to use from there to complete our dependencies).
- MySQL 5 rpms
(already in our testing repo)
- php 5 rpms (already provided)
- Open Office 2.0 rpms
(this is too hard to build and requires things we don't want to install on CentOS build machines ... but the OpenOffice website has RPMS that work OK)
- webmin
- rkhunter
- chkrootkit
- tripwire
(all or most of these are in dag)
- Adobe, Realplayer & Java plugins (though licensing might be a
hindrance)
(as Craig pointed out, we can't due to licensing issues, we also can't provide mp3 stuff)
- wine from winehq
{In KBS extras)
Using 3rd party repos is not bad, they just have to be used wisely with the tools that yum already provides. (includepkgs, exclude, enable ... and/or the protectbase plugin)
BTW, we don't do these things in a bubble either ... Jim Perrin (Evolution in IRC), Karanbir Singh (z00dax in IRC), Ignacio Vazquez- Abrams (ignacio in IRC), Pasi Pirhonen (blahee in IRC) and me (hughesjr in IRC) all work together to make the extras and centosplus repos work for CentOS 4. There is lots of discussion and testing before things get in there. The Fedora Extras stuff is not in there specifically because of the testing we require and we don't think it is quite stable enough (or has enough lifetime support). When something makes it into the Extras and/or CentOS Plus ... we are committing to maintaining it for the lifetime of CentOS 4. That is not someplace we can afford to bring stuff that we aren't sure will continue to be maintained.
Throw in Seth Vidal (skvidal in IRC), Tru Huynh(tru_tru in IRC) and Lance Davis (lancelan in IRC) for the CentOS-3 tree extras.
Thanks, Johnny Hughes
On 3/11/06, Jim Smith jim_smith2006@yahoo.com wrote:
I think Jim (the other one) is doing a marvellous job with extras and plus but he needs to expand the size of his tent. A sensible package policy in extras/plus repo will mean fewer temptations to install 3rd party repo's that can break your system. Some of the packages i would like to see are :-
- MySQL 5 rpms
- php 5 rpms (already provided)
- Open Office 2.0 rpms
- webmin
- rkhunter
- chkrootkit
- tripwire
- Adobe, Realplayer & Java plugins (though licensing might be a
hindrance)
- wine from winehq
Wow.. I leave to get some breakfast and you guys go and have the discussion without me! :-P
Johnny covered the basics pretty well. There's no real need to duplicate packages across repositories that work well together. As to the one package in the list ( feel free to suggest more ) that is built for centos but not in centosplus yet, we need feedback. Centos is to be stable, so we want to make sure that packages work. Mysql 5 has been built and rotting in the development repository because very few people are providing feedback as to the package's stability. It works well for me in production, but since I built it, I won't leave feedback for it. By all means use it, and if it works for you, leave the appropriate feedback in the tracking bugs assigned to me at bugs.centos.org.
The way it works. Packages for centosplus are submitted to the developers, we check package quality, build, stability, etc. We discuss the packages, and they go to the development repository. If they get enough positive feedback, they move to centosplus. If not, they sit there because ostensibly there is no one using/pushing for them. So if you use these rpms, then leave feedback.
Please, think of the orphaned packages in dev! Only you can prevent orphaned packages! Seriously, use them. Leave feedback. It helps us help the community by providing what they(YOU) want.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
I know about dag's repo from the bad old fedora days (when ATRPMS, LIVINA wouldn't play nicely), but his webmin is older than the official one.
On the subject of wine and winetools, the winehq rpms work properly with centOS. The KBS repo may not be aware of this situation and they have included a dud wine-tools (note the hyphen) which is not winetools.
The other issue is that for example i reinstalled apt, apt-devel and synaptic from centos extras and the rpmforge has newer versions of apt, apt-devel and synaptic. KBS repo if enabled would overwrite the rpmforge apt,apt-devel and synaptic even if KBS does not suupport apt4rpm.
I hope CentOS does not get to the "Fedora sharks repo" situation - where the repos compete and overwrite the base system files giving unexpected results.
Craig, where is the KDE-Redhat repo, I'm not a fan of KDE but if they have a newer SAMBA, I'll see whether it can quiten the logs.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sat, 2006-03-11 at 08:13 -0800, Jim Smith wrote:
I know about dag's repo from the bad old fedora days (when ATRPMS, LIVINA wouldn't play nicely), but his webmin is older than the official one.
---- indeed - and in fact, if you expect repos to always have the latest versions, then you should probably forget using repos and compile yourself. Since Jamie was sponsored by OpenCountry, webmin has been updating more frequently.
webmin however is a special case and I personally don't use anybody's rpm packaging but rather use the tarball and install from source. That's peculiar to webmin because it has a beautiful mechanism for updating itself. ----
On the subject of wine and winetools, the winehq rpms work properly with centOS. The KBS repo may not be aware of this situation and they have included a dud wine-tools (note the hyphen) which is not winetools.
The other issue is that for example i reinstalled apt, apt-devel and synaptic from centos extras and the rpmforge has newer versions of apt, apt-devel and synaptic. KBS repo if enabled would overwrite the rpmforge apt,apt-devel and synaptic even if KBS does not suupport apt4rpm.
I hope CentOS does not get to the "Fedora sharks repo" situation - where the repos compete and overwrite the base system files giving unexpected results.
---- I am not completely sure that I agree with the above. Sometimes you have to break eggs to cook them. Some packaging requires updated base modules to function...unfortunate but true. If 'upstream' refuses to update certain base packages, then they might have to be replaced by a repo to get other packages installed...you takes your chances. Good luck getting things like mythtv installed without updating some of the 'core' packages...which is why I think (rather unfairly), Axel Thimms gets a lot of heat for his repo...because he is actually making edge packages work and sometimes he has to break eggs.
I think the larger issue between Fedora repositories was standardization of naming that provided a logical system for one repository to evaluate its versioning against another and that seems to have gotten worked out in FC-4 repos. ----
Craig, where is the KDE-Redhat repo, I'm not a fan of KDE but if they have a newer SAMBA, I'll see whether it can quiten the logs.
---- kde-redhat.sourceforge.net
I doubt I would usually install an update for something that is functioning but is noisily logging...generally, the noisy logging is due to other circumstances.
Note that kde-redhat repo is packaging samba 3.0.21c and there are quite a few changes between that and the 3.0.10-x that CentOS-4 supplies.
And by the way, while we are on the subject - Thanks Johnny, Karanbir, Jim, Ignacio, Pasi, Lance for all your efforts...which are obviously taking a good amount of your time with all the updates recently released.
Craig
--- Craig White craigwhite@azapple.com wrote:
I am not completely sure that I agree with the above. Sometimes you have to break eggs to cook them. Some packaging requires updated
base
modules to function...unfortunate but true. If 'upstream' refuses
to update
certain base packages, then they might have to be replaced by a repo to get other packages installed...you takes your chances. Good
luck
getting things like mythtv installed without updating some of the
'core'
packages...which is why I think (rather unfairly), Axel Thimms gets a lot of heat for his repo...because he is actually making edge packages work and sometimes he has to break eggs.
Broken eggs? A good example is on the centos list http://lists.centos.org/pipermail/centos/2006-March/020471.html
That is a SURE lot of eggs to break for just mythtv.
I think the larger issue between Fedora repositories was standardization of naming that provided a logical system for one
repository to
evaluate its versioning against another and that seems to have
gotten worked
out in FC-4 repos.
Craig, where is the KDE-Redhat repo, I'm not a fan of KDE but if they have a newer SAMBA, I'll see whether it can quiten the logs.
kde-redhat.sourceforge.net
Arhh i recognize that repo as one of Axel Thims. I wouldn't touch anything from ATRMS/kde-redhat.sourceforge.net with a barge pole.
On the subject of Fedora since i haven't touched FC4, they may have ironed out the "repository hell" situation.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sat, 2006-03-11 at 09:01 -0800, Jim Smith wrote:
--- Craig White craigwhite@azapple.com wrote:
I am not completely sure that I agree with the above. Sometimes you have to break eggs to cook them. Some packaging requires updated
base
modules to function...unfortunate but true. If 'upstream' refuses
to update
certain base packages, then they might have to be replaced by a repo to get other packages installed...you takes your chances. Good
luck
getting things like mythtv installed without updating some of the
'core'
packages...which is why I think (rather unfairly), Axel Thimms gets a lot of heat for his repo...because he is actually making edge packages work and sometimes he has to break eggs.
Broken eggs? A good example is on the centos list http://lists.centos.org/pipermail/centos/2006-March/020471.html
That is a SURE lot of eggs to break for just mythtv.
---- why don't you set up mythtv and see for yourself what it entails - get back to me if you can do it without enabling Axel's repository.
I saw your email and saw the whine - seemed to me to be a user not knowing what he was doing and just adding everything. ----
I think the larger issue between Fedora repositories was standardization of naming that provided a logical system for one
repository to
evaluate its versioning against another and that seems to have
gotten worked
out in FC-4 repos.
Craig, where is the KDE-Redhat repo, I'm not a fan of KDE but if they have a newer SAMBA, I'll see whether it can quiten the logs.
kde-redhat.sourceforge.net
Arhh i recognize that repo as one of Axel Thims. I wouldn't touch anything from ATRMS/kde-redhat.sourceforge.net with a barge pole.
On the subject of Fedora since i haven't touched FC4, they may have ironed out the "repository hell" situation.
---- #1 kde-redhat.sourceforge.net (kde-redhat.repo) != atrpms If you don't know the difference, don't use either.
#2 whether you would touch a repo with a barge pole is an interesting commentary since you did, couldn't figure out what you had done and needed help cleaning it up...it makes sense that you do not venture into repositories without the tools to clean up the mess that you make. My guess is that you probably enabled something like atrpms 'testing' or 'unstable' repositories and your wounds were entirely self-inflicted.
#3 'repository hell' situation that you characterize...I would have never ascribed that characterization to issues between various repositories that existed with FC-3 - the solution was pretty clear, use either livna or dag/dries/freshrpms/atrpms - I always chose the latter...their packaging was better, fresher, more compatible.
Craig
To drag this thread back kicking and screaming to topic....
This is the mindset I've been operating with
1. Core packages will NOT be modified except by rpms in centosplus. 2. Packages in centosplus will provide more recent versions of core packages, such as php5, mysql5, rdesktop etc, or added functionality such as postfix with mysql and postgresql support. 3. Packages included in centosplus should be of sufficient quality that maintaining them over the lifespan of centos won't generate overly rapid change, or instability. 4. Packages will not be duplicated across cooperating repos. If dag has an older version, report it, or submit an update for inclusion. There's nothing that says you can't help out. If something in Kbs-Extras doesn't mesh, same deal. Centos is a 'community' based distribution. You're part of the community, kbs and dag are neighbors. Be nice to your neighbors. 5. Regular users who participate and provide feedback (yes, even negative so long as it is constructive) get will be heard first. I have no problem building things for people who request them, so long as time and work load allow, but I expect you to put the same effort into testing it, providing feedback etc. If you want to make demands without effort, I'll happily help you... via a consulting contract for a hefty fee :-P .
Comments? Questions?
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
--- Jim Perrin jperrin@gmail.com wrote:
To drag this thread back kicking and screaming to topic....
This is the mindset I've been operating with
- Core packages will NOT be modified except by rpms in centosplus.
- Packages in centosplus will provide more recent versions of core
packages, such as php5, mysql5, rdesktop etc, or added functionality such as postfix with mysql and postgresql support. 3. Packages included in centosplus should be of sufficient quality that maintaining them over the lifespan of centos won't generate overly rapid change, or instability. 4. Packages will not be duplicated across cooperating repos. If dag has an older version, report it, or submit an update for inclusion. There's nothing that says you can't help out. If something in Kbs-Extras doesn't mesh, same deal. Centos is a 'community' based distribution. You're part of the community, kbs and dag are neighbors.
On the subject of stability & built to work for CentOS :- - the rpms at http://www.winehq.com/site/download-rh (wine-0.9.2-1centos4winehq.src.rpm) do just that. There is no need to blindly follow the fedora rebuilds, 0.9.8 and 0.9.9 if the official wine rpms work as intended. The same goes for winetools (not wine-tools in fedora/kbs-extras)
WineTools http://www.von-thadden.de/Joachim/WineTools/ - WineTools is a menu driven installer for installing Windows programs. This software lets you install the following Windows software: DCOM98, IE6, Windows Core Fonts, Windows System Software, Office & Office Viewer, Adobe Photoshop 7, Illustrator 9 and many other programs.
Jim, if you maintain extras then tell me the need for you having apt, apt-devel & synaptic ; rpmforge having their versions (it would overwrite the extras one) and KBS which does not support apt having their own which would overwrite the extras & rpmforge ones.
The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback. What is the point of replacing core system files if all you need is mythtv?
Fedora is fedora. CentOS is CentOS. What is the purpose of a fedoralized CentOS?
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On the subject of stability & built to work for CentOS :-
- the rpms at http://www.winehq.com/site/download-rh
(wine-0.9.2-1centos4winehq.src.rpm) do just that. There is no need to blindly follow the fedora rebuilds,
Huh? Not a concern of mine. It's not in CentosPlus. As to the KBS-fedora rebuilds repository blindly following fedora rebuilds..... Have you fully thought that through? It's MEANT to be a rebuild of fedora extras...
WineTools http://www.von-thadden.de/Joachim/WineTools/ - WineTools is a menu driven installer for installing Windows programs. This software lets you install the following Windows software: DCOM98, IE6, Windows Core Fonts, Windows System Software, Office & Office Viewer, Adobe Photoshop 7, Illustrator 9 and many other programs.
Yes, I'm quite well aware of what it is.
Jim, if you maintain extras then tell me the need for you having apt, apt-devel & synaptic ; rpmforge having their versions (it would overwrite the extras one) and KBS which does not support apt having their own which would overwrite the extras & rpmforge ones.
Because users request it. Not everyone uses those repositories, and many larger users maintain their own repos. Personally I prefer yum, and apt was in the repo before I joined the centos team. I don't care if other repositories support it or not. It's entirely up to them.
The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback. What is the point of replacing core system files if all you need is mythtv?
No one ever said ATrpms was a cooperating repository. Dag is frequently in irc and the developers channel discussing things. KBS is built by a centos maintainer. If you have a problem with a particular repository, then don't use them.
Fedora is fedora. CentOS is CentOS. What is the purpose of a fedoralized CentOS?
Centosplus and centos extras hardly lead to a fedoralized centos. Please lay off the blatantly false and inflammatory rhetoric. It leads to postfix with database support, and other such useful backend server items.
I'm not sure that this thread will become as productive as it started out, so until it does... I have better things to do.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
What I'd like to see in Centosplus is a rpm of Xen, that is stable and pre-tested with Centos and seamlessly changes the Centos Server/Workstation. I have tinkered with a knoppix 4 version with xen built into the kernel, but when it comes to the decision of building a XENized kernel and then daring to deploy on my sole web-server, my breath jams in my throat ;-(
In addition, I believe its time when Centos has a wiki which shows less experienced users like me, how to do something, posted by those who have attempted and done something with centos. Each of these wiki threads could end up becoming centos how-tos. Topics could range from installing Xen, GFS, hardening security, doing minimal installs, installing asterisk or other voip, plone, drupal or other CMS or blogs or even installing codecs for audio-video that don't come pre-installed.
In the enterprise, there's always a repungence to trying something untested or rather on your own, especially like less experienced users, especially those with shoe-string budget. The reassurance of walking on a well-trodden path with road-signs given to you, is a great plus in deciding to do something with Centos.
I agree, all these how-tos are out there, all one needs to do is Google and one would find N number of How-tos but most of time they refer to a different distribution and one has to go through the painful process of learning the pecularities of other linuses (linuxes ?) and adapting them to the one we use, namely Enterprise Linux or Centos.
Maybe its the effect of commerce but most of literature on the net is not adapted to enterprise linux, at least that's my experience...your milage may vary! I think Centos community leaders should look a little in this issue & debate and then maybe implement something around these lines. Enablement of Enterprise Applications around the stable Centos Core shuld be the path ahead.
Just my two rupees worth ;-) I belong to India, so can't give in US cents ;-)
With regards. Sanjay.
On Sun, Mar 12, 2006 at 10:09:07PM +0530, Sanjay Arora wrote:
What I'd like to see in Centosplus is a rpm of Xen, that is stable and pre-tested with Centos and seamlessly changes the Centos Server/Workstation.
Yes, this would be really nice.
............. In addition, I believe its time when Centos has a wiki which shows less experienced users like me, how to do something, posted by those who have attempted and done something with centos. Each of these wiki threads could end up becoming centos how-tos. Topics could range from installing Xen, GFS, hardening security, doing minimal installs, installing asterisk or other voip, plone, drupal or other CMS or blogs or even installing codecs for audio-video that don't come pre-installed.
A Centos-Enterprise oriented wiki is a great idea. We need a place to host it. Does Centos.org have the resources to add this to their site? (= extra storage, Bandwidth, time to install and administer or willingness to let others on their server to do same?)
Its a lot too ask, but if Centos.org is willing, then great.
Donovan, what do you think?
Or are there any other community members who could host a wiki?
It doesn't have to be a wiki per se. Any mechanism that allows contributors to add pages to a web site (even via email) would be a useful tool. Static html is fine (and may even be best.)
In the enterprise, there's always a repungence to trying something untested or rather on your own, especially like less experienced users, especially those with shoe-string budget. The reassurance of walking on a well-trodden path with road-signs given to you, is a great plus in deciding to do something with Centos.
............. milage may vary! I think Centos community leaders should look a little in this issue & debate and then maybe implement something around these lines. Enablement of Enterprise Applications around the stable Centos Core shuld be the path ahead.
I would guess the Centos leaders already have full plates just keeping the Centos distribution going. Perhaps we community members need to step up to the plate to create this.
I can volunteer some time to install and administer a wiki. Mediawiki is a very powerful wiki system. Its the one Wikipedia uses but its slow and very resource intensive. If we have to run a wiki we should run one that is lighter.
Just my two rupees worth ;-) I belong to India, so can't give in US cents ;-)
I'll take it! 2 INR for $0.02 USD is a great exchange rate. :-)
On 3/12/06, Jeff Kinz jkinz@kinz.org wrote:
On Sun, Mar 12, 2006 at 10:09:07PM +0530, Sanjay Arora wrote:
What I'd like to see in Centosplus is a rpm of Xen, that is stable and pre-tested with Centos and seamlessly changes the Centos Server/Workstation.
Yes, this would be really nice.
A Centos-Enterprise oriented wiki is a great idea. We need a place to host it. Does Centos.org have the resources to add this to their site? (= extra storage, Bandwidth, time to install and administer or willingness to let others on their server to do same?)
Its a lot too ask, but if Centos.org is willing, then great.
Donovan, what do you think?
Or are there any other community members who could host a wiki?
It doesn't have to be a wiki per se. Any mechanism that allows contributors to add pages to a web site (even via email) would be a useful tool. Static html is fine (and may even be best.)
In the enterprise, there's always a repungence to trying something untested or rather on your own, especially like less experienced users, especially those with shoe-string budget. The reassurance of walking on a well-trodden path with road-signs given to you, is a great plus in deciding to do something with Centos.
............. milage may vary! I think Centos community leaders should look a little in this issue & debate and then maybe implement something around these lines. Enablement of Enterprise Applications around the stable Centos Core shuld be the path ahead.
I would guess the Centos leaders already have full plates just keeping the Centos distribution going. Perhaps we community members need to step up to the plate to create this.
I can volunteer some time to install and administer a wiki. Mediawiki is a very powerful wiki system. Its the one Wikipedia uses but its slow and very resource intensive. If we have to run a wiki we should run one that is lighter.
Just my two rupees worth ;-) I belong to India, so can't give in US cents ;-)
I'll take it! 2 INR for $0.02 USD is a great exchange rate. :-)
;-)) Yeh...u'll get a lot for that dollar! Thanks Jeff
BTW, Centos already has forums at http://www.centos.org/modules/newbb/index.php however, its QA oriented normal Wiki, with high noise ratio and is not much different from a mailing list except in its presentation.
What I envisage is having a section on How-to, further subsections like RDBMS, ODBMS, CMS, Groupware, Helpdesk, Email, Backup, somehow the "first post moderated" by someone from a group of people very experienced in CentOS (purpose each How-to allowed to be posted as a thread to be a complete how-to on deploying maintaining one RDBMS, if RDBMS section & so on, with detailed instructions & links for further research).
Just imagine, I am looking for a CMS, I visit the forum & find neatly laid in 5 threads, 5 different CMS under the CMS Howto Section, a howto, followup comments, problem areas, scripts, experiences & so on.
Incomplete Articles not to be allowed by moderator. Allowed articles may/may not have comments added in a follow-up, by the moderator team, maybe showing some enhancements that can be done.
Rest of posts to the thread can be by the community, people who have tried following howto, success reports, comments, QA and mabe even scripts built using the How-to. These need not be moderated.
A small script may be written which may create an index page of all howtos from the subject lines or something.
With regards. Sanjay.
Sanjay Arora wrote:
On 3/12/06, Jeff Kinz jkinz@kinz.org wrote:
On Sun, Mar 12, 2006 at 10:09:07PM +0530, Sanjay Arora wrote:
What I'd like to see in Centosplus is a rpm of Xen, that is stable and pre-tested with Centos and seamlessly changes the Centos Server/Workstation.
Yes, this would be really nice.
A Centos-Enterprise oriented wiki is a great idea. We need a place to host it. Does Centos.org have the resources to add this to their site? (= extra storage, Bandwidth, time to install and administer or willingness to let others on their server to do same?)
Its a lot too ask, but if Centos.org is willing, then great.
Donovan, what do you think?
Or are there any other community members who could host a wiki?
there has already been a bit of planning for a http://wiki.centos.org/ - and a few various wiki s/w were looked at a few weeks back, settling on moin.
A fair few good points have been raised here about the various options and issues we could address on such a wiki. Can we fix up a time/date for a meeting on irc #centos-devel and thrash out the issues once ?
Jeff, there is no hosting issue - the infrastructure is already in place, the software too - just needs to be moved into the final place. But that will only happen once we have a clear idea of what content is going in there, and how its going to be structured.
The usual suspects are normally online 15:00 - 17:00 hrs GMT - could we have a session about the wiki.centos.org setup on Tues 21st Mar 16:00 ? Lance should also be back by then.
On 3/13/06, Karanbir Singh mail-lists@karan.org wrote:
there has already been a bit of planning for a http://wiki.centos.org/ - and a few various wiki s/w were looked at a few weeks back, settling on moin.
Long post below.....don't sleep ;-))
Enterprise Strategy for myself using CentOS...some thoughts...maybe you guys will find some insight in this for your planning.
Some Background: Indian SME, using 5 Desktops (now Centos...only one machine Windoz Dual-boot), One IPcop firewall on the 256 Kbps ADSL, Five Servers (all Centos), Samba File Server (with mySQL, apache & qmail/vpopmail installed), INN News Server (NNTP + Mailing lists thru mail2news), Database Server postgreSQL & minor mySQL install (minimally used), BackupPC for entire network backup to large capacity HDDs (4 x 300 GB) on the LAN and one machine in the DMZ with apache & associated web-tools, postgresql, mysql, qmail/vpopmail with spamassasin & clam, getmail for gmail.
All machines are minimally installed for their function & only the desktops are installed with full options, though server daemons are stopped. I do NOT need anything out of the CentOS repo for these....all are stable applications on CentOS.
When Redhat slapped support on EL, I was in a hell of fix. In a haphazard way tried different distros until I installed whitebox from which I shifted to CentOS. I was then planning to phase our Windoz and therefore Redhat action was a major setback because I got no budget...let alone a shoestring one. Guess I need to thank you guys for the job that you do....mostly thankless, I guess...so here goes...THANKS, GUYS!
Now that I evaluate the IT requirements for the future of my SME Company, basic requirements remain the same except for a few changes. I guess it would apply to various enterprises, milages may vary, due to Internet Access type/costs & other issues.
Four major areas I foresee for any SME and maybe for biggies too..
1. Firewalling...distributed...not only on the perimeter, easily available with iptables, maybe even with canned scripts & GUI tools like fwbuilder that I am currently evaluating BUT major area is a GUI based approach on centralized logs...ACID etc...again all available, I think without breaking CentOS repo updates, though rpms would be lovely ;-)
2. Intranet/Extranet/Portal...This is for the DMZ Web/mail Server & the Intranet Server on the LAN. Many could make do with CMSs with no changes to their repo requirements. Some, especially those with workflow aspirations like myself would go for solutions like Plone/Zope/latest python combo, which would break the Centos repo update path & hence the security/stability of the systems.
3. Desktop Applications...This is the area where CentOS lags behind. Enterprise does require stability, but workstations used by the staff need a major push...nobody is happy due to minor issues like playing music, video, glitches of java & flash with firefox...many ask for one or the other app that leads to repo hell.
4. Disaster Recovery...and I do not mean backing up a continent away or recovering from Katrina etc., all one needs is recovering from a failed HDD or restoring from backup or providing services from another machine while upgrading one...all very everyday...buy invariably all pains in the butt...;-(
Enter XEN...Virtualization technologies are going to be a very important player to the enterprise. I plan on going for Xen in a major way....if my distro will support...great...but I don't have a choice as I see it...I got to master it.
As I see it, my basic infrastructure in point 1 (Servers) is stable and no need to change anything there, except to virtualize each of the services provided by these servers and thereby provide failover/disaster recovery. I am not talking HA/Carp etc., only being able to restore service from another machine from a web-based interface on my intranet.
Coming to Desktops & DMZ web/mail server, they do need to break from the CentOS repo & business is business...you gotta do what you gotta do. Enter Xen again, I maintain each service in a seperate Xen domu, each service in a seperate compartment and unaffected by the other...you end up doing one or two violations in each domu, basic Centos in each is kept with minimal repo changes. I want to convert repo hell to repo trouble!
All very easy to say..in this very long post...but its going to be a very long and painful process. This is where I believe a movement in the CentOS community can make a difference....using the wiki & a defined ENABLEMENT process...lets call it CentOS enables your applications movement or something equally syrupy ;-)
I believe the wiki should be divided into application forums further subdivided into application software e.g. Centos Wiki -> mail -> qmail -> Various threads of qmail how-to, each a complete howto of a given application on Centos e.g. qmailrocks.org on Centos Howto or qmailtoaster on Centos Howto or Qmail/vmailmanager on CentOS from source howto.
These howtos should be moderated by group wise moderators who are knowledgable about that application, maybe even a couple of users (those who use any form of EL) from that application's mailing list should be invited to help moderate the thread or forum.
Tested installs from these howtos should find their way into CentOS contrib repo, so average users can start using these, without going too far away from the home fires ;-)
Another thing...community should be mentored & encouraged in learning to package software in rpms for centos and contribute. The mentors can test & check the package...thats the only way community can really grow...Karan & his fellow sufferers can do only so much for us ;-)
Take me, I know how to deploy from binary/src rpm and from source but just ask me to package something for my system & I'll probably faint ;-) This is what needs to change!
Hope I have not bored you guys too much...those that have fallen asleep, please do wake up. My harrasement of you is over ;-)
With best regards. Sanjay.
If there was a wiki, I would certainly add information to it.
I be a lot of potential users don't know that CentOS 4.2 can be the ideal laptop distro for a wireless network admin (madwifi drivers from atrpms, wavemon, kismet, etc).
The RHEL documentation leaves out a lot regarding desktop and laptop applications.
On Sunday 12 March 2006 11:57 am, Jeff Kinz wrote:
Perhaps we community members need to step up to the plate to create this.
Jim Smith wrote:
The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback.
feel free at this stage, to point out what efforts you made to report these problems to the repo maintainers, before arriving at your conclusion, I for one can assure everyone here that you made absolutely not effort to get in touch with me at any point.
Fedora is fedora. CentOS is CentOS. What is the purpose of a fedoralized CentOS?
feel free to not use the repo then. its not being forced down your throat.
- KB
On Sunday 12 March 2006 09:14, Jim Smith wrote:
The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback. What is the point of replacing core system files if all you need is mythtv?
Ok, let me give you a scenario or three.
Suppose you want, say, GNUradio on your CentOS box. (I use this example because I use GNUradio on my CentOS box....)
GNUradio requires a significantly more recent version of SWIG than ships with CentOS 4. Ok, if you are going to package a repo for GNUradio (which I plan on doing at some point) you WILL have to replace the existing SWIG or make a parallel SWIG for GNUradio. What can you do otherwise? There are also other items that GNUradio will require; fortunately the big one, FFTW 3, isn't part of the base CentOS, and that particular library has to be built with nonstandard options.
Second scenario: you want Plone 2.1.2 on Zope 2.8. Ok, this means you need Python 2.4. CentOS 4 ships Python 2.3.4, and the Zope build will die if you try it on that Python. What do you do? You can either replace the core Python, or make a parallel Python; neither task is easy (on the surface, a parallel Python seems easy; in practice is is not, and can require large patches to programs that require the parallel version....). ATrpms has a Python24, but then you need the rest of the ATrpms repo.....
Third scenario: you want the version of Kstars that does telescope control (see my .sig for why I might want this). This requires a much later KDE than the 3.3.1 shipped with CentOS 4. The later KDE builds REQUIRE a LOT of core library changes, touching over half of the distribution. Rex Dieter has done an amazing job with KDE-RedHat for EL4, and, frankly, that is a thankless job, because if you choose to use KDE-RedHat you can break many many many other packages and repos that rely on the CentOS-default KDE 3.3.1. I have found Rex to be very responsive to repository issues from first-hand experience, and the quality of the packages seems as good as most others. No, they are not 'blessed' by the CentOS core, and that's OK.
Axel Thimm (who also has a very thankless job, having taken on the maintenance of some quite cutting edge software and trying to make it work with Scientific Linux 4 (the packages for which work fine on other EL4 distros, but keep in mind that Axel is packaging for and with SL4, not CentOS 4)) is packaging mythtv, which requires several extra libraries, and not charging you a penny for it. If you can get that package set to build without all the other changes that have to be made, then by all means go for it. In the case of mythtv, ATrpm's packages are built within the framework of the rest of ATrpms; thus, those mythtv packages (rebuild mythtv from source to see why) require the rest of ATrpm's infrastructure; does it make any sense any other way?
But it is rude and off-base, in my opinion, to call a dedicated third-party packager 'cuckoo' simply because they do it differently, or because they HAVE to replace large parts of the core distribution to get their packages to work. The CentOS base package set is showing its age, as are all other RHEL4 rebuilds, and RHEL4 itself; this is one of the downsides to using an 'Enterprise' Linux.
Third party repository interaction is an old problem, and one that is not going to go away anytime soon. If you choose to use a third party repo, and it breaks your box, you get to keep the pieces. Unless you are willing to pay someone to maintain the exact set of packages that you want, or are willing to maintain them yourself, then you really don't have any room to complain to a great degree; that is, before you enable that third-party repo file, you had best find out what it is going to do to your system, and then you NEVER just 'yum -y upgrade' while a third-party repo is enabled, otherwise you get what you get.
This means that sometime you have to choose which set of third party packages you want, and go with that set, ignoring all others. The PlanetCCRMA packages for FC are along those lines; you want those features, you pretty well must use that repo exclusively. KDE-RedHat is also in that category, since so many packages have to be changed to get KDE 3.5.1 (the current release) working. ATrpms, because of some of the software being packaged, must also do this. DAG and the rest of the RPMforge set likewise; I ran a machine once with FC2, DAG, ATrpms, and KDE-RedHat all enabled at the same time, and it was not pretty. But since I chose to enable all three, I got to keep the pieces and I had to fix the problems, which were many and continuous; that machine happened to be my main work laptop, which is now running CentOS 4 with KDE-RedHat and Karanbir's Extras (which for the most part mixes OK with KDE-RedHat, as long as I don't pull over a KDE 3.3.1-packaged extra from Karanbir's Extras).
Now, as to why someone would want to 'Fedorize' their CentOS rather than just run Fedora, well, there are some instances where such a thing is useful. Again, I use the Kstars example; one might say 'well, why not just run Fedora' to which I would answer 'I don't want to completely reinstall machines every six months; besides, KDE-RedHat exists and works fine, and I get the base stability of the CentOS kernel and glibc, and I then can leverage my standardization on CentOS 4 for all my servers'. I have been on the Fedora roller-coaster, and I don't like it. Although I may have to deal with the CentOS roller coaster (since I will probably upgrade to CentOS 5 once such a beast is in the pipeline, because the preview in FC5 of what is likely to be in RHEL 5 is compelling for upgrade, at least on desktops), at least that roller coaster is on a longer cycle.
Even Debian is now having this sort of problem, with Knoppix and Ubuntu in the mix, neither of which is a vanilla Debian.
--- Lamar Owen lowen@pari.edu wrote:
But it is rude and off-base, in my opinion, to call a dedicated third-party packager 'cuckoo' simply because they do it differently, or because they HAVE to replace large parts of the core distribution to get their packages to work. The CentOS base package set is showing its age, as are all other RHEL4 rebuilds, and RHEL4 itself; this is one of the downsides to using an 'Enterprise' Linux.
Not cuckoo repos, don't misquote me- THEIR DEVELOPERS ARE LIVING IN A CUCKOO WORLD & they do not respond to feedback nor work with other developers. This is why you have apt, apt-devel and synaptic in all the repos.
Now, as to why someone would want to 'Fedorize' their CentOS rather than just run Fedora, well, there are some instances where such a thing is useful. Again, I use the Kstars example; one might say 'well, why not just run Fedora' to which I would answer 'I don't want to completely reinstall machines every six months; besides, KDE-RedHat exists and works fine, and I get the base stability of the CentOS kernel and glibc, and I then can leverage my standardization on CentOS 4 for all my servers'. I have been on the Fedora roller-coaster, and I don't like it. Although I may have to deal with the CentOS roller coaster (since I will probably upgrade to CentOS 5 once such a beast is in the pipeline, because the preview in FC5 of what is likely to be in RHEL 5 is compelling for upgrade, at least on desktops), at least that roller coaster is on a longer cycle.
You cannot have your cake and eat it. What will happen when the stuff in the Fedoralized repo begins to churn out FC5 stuff? If you want fedora stick to fedora. If you want a stable enterprise distro go for RHEL/CentOS.
Have you run wine/winetools from winehq.com versus the fedoralized one? Which one works and which one doesn't?
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Monday 13 March 2006 11:38, Jim Smith wrote:
--- Lamar Owen lowen@pari.edu wrote:
But it is rude and off-base, in my opinion, to call a dedicated third-party packager 'cuckoo' simply because they do it differently, or because
Not cuckoo repos, don't misquote me- THEIR DEVELOPERS ARE LIVING IN A CUCKOO WORLD & they do not respond to feedback nor work with other developers. This is why you have apt, apt-devel and synaptic in all the repos.
Who is 'they'? Your original statement was "The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback." If you are talking about the maintainers of the repos, then I did not misquote you.
You cannot have your cake and eat it.
No, but I CAN have my Kstars and CentOS too. And it works, as long as I am careful and take responsibility for my own /etc/yum.repos.d.
What will happen when the stuff in the Fedoralized repo begins to churn out FC5 stuff?
Then I will deal with that when and if it happens. Been there, done that. Have the changelog entries in the PostgreSQL spec file to prove it.
If you want fedora stick to fedora. If you want a stable enterprise distro go for RHEL/CentOS.
The choice is not either/or, nor is it black/white. There is a continuum of choice that the third party repos provide, as long as you take responsibility for mixing. 'You' in this case being the admin of the system; the third part repo maintainers are simply providing what they want to provide, and are answerable only to themselves.
If you are paying someone to do the support, then you can hold them accountable; like if you were running Red Hat Enterprise Linux. If you are not paying them for support, then you are accountable for your own system.
Have you run wine/winetools from winehq.com versus the fedoralized one? Which one works and which one doesn't?
I use CrossOver; wouldn't know about the others.
Karanbir advertises his repo as a Fedora Extras rebuild; nothing more, nothing less. This is what he wants to provide, and what he is providing. If that doesn't meet your need, either find someone else's repo that does or make your own repo.
Not cuckoo repos, don't misquote me- THEIR DEVELOPERS ARE LIVING IN A CUCKOO WORLD & they do not respond to feedback nor work with other developers. This is why you have apt, apt-devel and synaptic in all the repos.
Here's the beauty of open source. If you're not happy with something FIX IT. You have all the tools you need freely at your disposal. If you have a good product, others will use it and hopefully help out. No one is forcing you to use any particular repository or package here. You're using software that you don't have to pay for, so put a little effort in on your own.
Have you run wine/winetools from winehq.com versus the fedoralized one? Which one works and which one doesn't?
Same deal. You're not being forced to use one or the other. Fix the issue, report it to the repo maintainer, start your own repository, or quit bitching. There are several options to choose from. The current method of bitching here is unproductive, and will not lead you to results.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
Jim Smith wrote:
Not cuckoo repos, don't misquote me- THEIR DEVELOPERS ARE LIVING IN A CUCKOO WORLD & they do not respond to feedback nor work with other developers.
Jim,
how would you know this ? you've not even made the effort to contact any of them....
well, not me anyway.
- KB
On Mon, 2006-03-13 at 10:38, Jim Smith wrote:
You cannot have your cake and eat it.
That's just an unfortunate design decision of RPM and package conventions that you can't install a new/different version without clobbering your old one. Most applications wouldn't really care if you had multiple versions installed. At least it has been worked around with the kernel...
What will happen when the stuff in the Fedoralized repo begins to churn out FC5 stuff? If you want fedora stick to fedora. If you want a stable enterprise distro go for RHEL/CentOS.
Maybe someday a distribution will figure out that users really want a stable OS along with current apps instead of bundling new device drivers along with version-level desktop app updates. Until then, or at least until packaging lets you install new/expermental versions alongside your well-tested working application, people will continue to do strange and desperate things...
On Monday 13 March 2006 13:59, Les Mikesell wrote:
Maybe someday a distribution will figure out that users really want a stable OS along with current apps instead of bundling new device drivers along with version-level desktop app updates. Until then, or at least until packaging lets you install new/expermental versions alongside your well-tested working application, people will continue to do strange and desperate things...
Let me make a minor edit to this well-thought-out paragraph, Les. The change is from 'distribution' to 'upstream open-source developers who have a NIH attitude and who insist on their required version of any given library as being The Only Acceptable Version'. Typically the distribution has very little control on what the upstream requires (this isn't strictly true for Red Hat or Novell, since they employee a good sized percentage of upstream developers.
Thus the need to keep so many versions of, say, GTK or OpenSSL in the distribution. It goes back to the upstream's willingness to work with older versions of libraries. And, in this case, I'm not referring to Red Hat as the upstream; I referring to MySQL AB, the PostgreSQL Global Development Group, the KDE project, the GCC and GLIBC developers, the Linux developers, etc.
On Mon, 2006-03-13 at 15:26, Lamar Owen wrote:
On Monday 13 March 2006 13:59, Les Mikesell wrote:
Maybe someday a distribution will figure out that users really want a stable OS along with current apps instead of bundling new device drivers along with version-level desktop app updates. Until then, or at least until packaging lets you install new/expermental versions alongside your well-tested working application, people will continue to do strange and desperate things...
Let me make a minor edit to this well-thought-out paragraph, Les. The change is from 'distribution' to 'upstream open-source developers who have a NIH attitude and who insist on their required version of any given library as being The Only Acceptable Version'.
I'm not sure I even care about that. While I'd rather not have every app statically link every library, I can afford the disk space to have versioned shared libs for everything that really needs them. That seems to be more reasonable than to expect Linux developers to accept the definition of interfaces as contracts among programmers that aren't supposed to ever change.
Typically the distribution has very little control on what the upstream requires (this isn't strictly true for Red Hat or Novell, since they employee a good sized percentage of upstream developers.
Thus the need to keep so many versions of, say, GTK or OpenSSL in the distribution.
I can live with that. That doesn't explain why I can't have an RPM-installed evolution 2.x alongside the stock Centos 3.x version.
It goes back to the upstream's willingness to work with older versions of libraries. And, in this case, I'm not referring to Red Hat as the upstream; I referring to MySQL AB, the PostgreSQL Global Development Group, the KDE project, the GCC and GLIBC developers, the Linux developers, etc.
Respecting existing interfaces in existing libraries during new development would pretty much eliminate the need to keep old versions around, but I don't see much hope for that. A better workaround to let multiple versions of everything co-exist is probably the best we might see.
On Monday 13 March 2006 17:27, Les Mikesell wrote:
On Mon, 2006-03-13 at 15:26, Lamar Owen wrote:
Let me make a minor edit to this well-thought-out paragraph, Les. The change is from 'distribution' to 'upstream open-source developers who have a NIH attitude and who insist on their required version of any given library as being The Only Acceptable Version'.
I'm not sure I even care about that. While I'd rather not have every app statically link every library, I can afford the disk space to have versioned shared libs for everything that really needs them.
Can you afford the bandwidth? Updates are already 2-3GB per year. I'll say again; if Microsoft were to require 2GB per year to stay up-to-date people would be up in arms....
That seems to be more reasonable than to expect Linux developers to accept the definition of interfaces as contracts among programmers that aren't supposed to ever change.
It's not even interface definitions. It's whole languages. It's whole libraries; GTK1.2 versus GTK2 or QT3 versus QT4, for instance. Those are setup now to coexist.
I can live with that. That doesn't explain why I can't have an RPM-installed evolution 2.x alongside the stock Centos 3.x version.
To do this you need to keep all dependencies of all programs that you wish to do this with. I would think there aren't enough packagers in the typical distribution's shop to handle that many packages.
Also, the upstream has to respect the multiple version capability. Things like, oh, maildirs need to be intelligently addressed and not blindly upconverted.
Respecting existing interfaces in existing libraries during new development would pretty much eliminate the need to keep old versions around, but I don't see much hope for that. A better workaround to let multiple versions of everything co-exist is probably the best we might see.
Multiple versions of everything....good thing disks are getting bigger...
That is probably the best we'll see. But we also have to come to grip with the idea that there is no ideal Linux distribution; not just for all users, but even for all programs.
On Mon, 2006-03-13 at 11:10 -0500, Lamar Owen wrote:
On Sunday 12 March 2006 09:14, Jim Smith wrote:
The problem with some of the 3rd party repos that overwrite system files, (look at the example i gave of one repo even wanting to overwrite selinux) is that the maintainers live in a cuckoo world and do not respond to feedback. What is the point of replacing core system files if all you need is mythtv?
Ok, let me give you a scenario or three.
Suppose you want, say, GNUradio on your CentOS box. (I use this example because I use GNUradio on my CentOS box....)
GNUradio requires a significantly more recent version of SWIG than ships with CentOS 4. Ok, if you are going to package a repo for GNUradio (which I plan on doing at some point) you WILL have to replace the existing SWIG or make a parallel SWIG for GNUradio. What can you do otherwise? There are also other items that GNUradio will require; fortunately the big one, FFTW 3, isn't part of the base CentOS, and that particular library has to be built with nonstandard options.
Second scenario: you want Plone 2.1.2 on Zope 2.8. Ok, this means you need Python 2.4. CentOS 4 ships Python 2.3.4, and the Zope build will die if you try it on that Python. What do you do? You can either replace the core Python, or make a parallel Python; neither task is easy (on the surface, a parallel Python seems easy; in practice is is not, and can require large patches to programs that require the parallel version....). ATrpms has a Python24, but then you need the rest of the ATrpms repo.....
Third scenario: you want the version of Kstars that does telescope control (see my .sig for why I might want this). This requires a much later KDE than the 3.3.1 shipped with CentOS 4. The later KDE builds REQUIRE a LOT of core library changes, touching over half of the distribution. Rex Dieter has done an amazing job with KDE-RedHat for EL4, and, frankly, that is a thankless job, because if you choose to use KDE-RedHat you can break many many many other packages and repos that rely on the CentOS-default KDE 3.3.1. I have found Rex to be very responsive to repository issues from first-hand experience, and the quality of the packages seems as good as most others. No, they are not 'blessed' by the CentOS core, and that's OK.
Right ... not blessed because they change some major things like the samba version, etc. This is not necessarily a bad thing, but the end result is not CentOS. I have a test machine running KDE-RedHat ... it is more stable than FC (for example).
Axel Thimm (who also has a very thankless job, having taken on the maintenance of some quite cutting edge software and trying to make it work with Scientific Linux 4 (the packages for which work fine on other EL4 distros, but keep in mind that Axel is packaging for and with SL4, not CentOS 4)) is packaging mythtv, which requires several extra libraries, and not charging you a penny for it. If you can get that package set to build without all the other changes that have to be made, then by all means go for it. In the case of mythtv, ATrpm's packages are built within the framework of the rest of ATrpms; thus, those mythtv packages (rebuild mythtv from source to see why) require the rest of ATrpm's infrastructure; does it make any sense any other way?
But it is rude and off-base, in my opinion, to call a dedicated third-party packager 'cuckoo' simply because they do it differently, or because they HAVE to replace large parts of the core distribution to get their packages to work.
This is absolutely true ... if you want that functionality, you have to use those pacakges. Axel does a great job ... I am using his mythTV on a CentOS machine. BUT, I don't expect that machine to rock solid stable like the other centos machines I have. It isn't good or bad ... it just is, if you want MythTV on an machine, it requires some cutting edge packages, that is just the way it is.
The CentOS base package set is showing its age, as are all other RHEL4 rebuilds, and RHEL4 itself; this is one of the downsides to using an 'Enterprise' Linux.
This is also absolutely true ... Enterprise Linux is designed for stability, it is not designed for "Latest and Greatest". In fact, Fedora is a very good Latest and Greatest distro, if that is what you are trying to accomplish.
You will notice that the Unbuntu guys now want a 6 week delay to roll out their latest version as they get stuff just right to support it for more than a year (they are trying to make the new version be Enterprise).
Third party repository interaction is an old problem, and one that is not going to go away anytime soon. If you choose to use a third party repo, and it breaks your box, you get to keep the pieces. Unless you are willing to pay someone to maintain the exact set of packages that you want, or are willing to maintain them yourself, then you really don't have any room to complain to a great degree; that is, before you enable that third-party repo file, you had best find out what it is going to do to your system, and then you NEVER just 'yum -y upgrade' while a third-party repo is enabled, otherwise you get what you get.
Good wisdom in the above paragraph :)
This means that sometime you have to choose which set of third party packages you want, and go with that set, ignoring all others. The PlanetCCRMA packages for FC are along those lines; you want those features, you pretty well must use that repo exclusively. KDE-RedHat is also in that category, since so many packages have to be changed to get KDE 3.5.1 (the current release) working. ATrpms, because of some of the software being packaged, must also do this. DAG and the rest of the RPMforge set likewise; I ran a machine once with FC2, DAG, ATrpms, and KDE-RedHat all enabled at the same time, and it was not pretty. But since I chose to enable all three, I got to keep the pieces and I had to fix the problems, which were many and continuous; that machine happened to be my main work laptop, which is now running CentOS 4 with KDE-RedHat and Karanbir's Extras (which for the most part mixes OK with KDE-RedHat, as long as I don't pull over a KDE 3.3.1-packaged extra from Karanbir's Extras).
Now, as to why someone would want to 'Fedorize' their CentOS rather than just run Fedora, well, there are some instances where such a thing is useful. Again, I use the Kstars example; one might say 'well, why not just run Fedora' to which I would answer 'I don't want to completely reinstall machines every six months; besides, KDE-RedHat exists and works fine, and I get the base stability of the CentOS kernel and glibc, and I then can leverage my standardization on CentOS 4 for all my servers'. I have been on the Fedora roller-coaster, and I don't like it. Although I may have to deal with the CentOS roller coaster (since I will probably upgrade to CentOS 5 once such a beast is in the pipeline, because the preview in FC5 of what is likely to be in RHEL 5 is compelling for upgrade, at least on desktops), at least that roller coaster is on a longer cycle.
That is also a good point ... a CentOS with updates might prove to be more long lived and more stable than a FC distro, and people might want to do that ... but they should not expect CentOS to support it :)
Even Debian is now having this sort of problem, with Knoppix and Ubuntu in the mix, neither of which is a vanilla Debian.
I just want to point out that I agree with almost everything that Lamar said here.
I also want people to understand that CentOS 5 will be released in the not to distant future .. and we are not trying to make CentOS 4 BE CentOS 5 before it is released. We do add some things to CentOS 4 for longevity (like mysql5 and php5 and XFCE, etc.).
BUT ... CentOS is not interested in duplicating things in KBS-CentOS- Extras, dag, dries, ATRPMS, KDE-Redhat, etc.
A question was asked about APT ... and why CentOS released it even though it is released other places. In this instance, apt was released by CentOS so that the apt sources file could be created and that you didn't have 3rd party repos enabled by default. It was provided as an extra for doing CentOS updates by people who wanted to do that. Since we did not want to enable 3rd party repos by default, a new version of apt for centos was required.
This happened BEFORE fedora extras included apt and before fedora extras was built by Karanbir.
Thanks, Johnny Hughes
-
Chris Mauritz -
Craig White -
Jeff Kinz -
Jim Perrin -
Jim Smith -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
ryan -
Sanjay Arora