Hello, every one. Is it possible to merge elrepo.org contribute to centos main repository?elrepo.org contribute the latest hardware driver and latest kernel for centos.Using it for a longtime, just want to know if it possible to got it merged to centos main repository. What we expected? The latest kernel cotains more optimizer for filesystem driver. such as XFS.
zf@ancientrocklab.com
On 02/24/2014 06:49 PM, zf@ancientrocklab.com wrote:
Hello, every one. Is it possible to merge elrepo.org contribute to centos main repository?elrepo.org contribute the latest hardware driver and latest kernel for centos.Using it for a longtime, just want to know if it possible to got it merged to centos main repository. What we expected? The latest kernel cotains more optimizer for filesystem driver. such as XFS.
Short answer? No.
Long answer:
1. The base repository design will not change. These packages could be accepted into a SIG or variant build, but they will never be in base.
2. Elrepo is an entirely separate project that we have no control over. It's entirely up to them to decide if they want to go this route. We could certainly welcome them, but it's not our decision to make.
On 25/02/14 15:12, Jim Perrin wrote:
On 02/24/2014 06:49 PM, zf@ancientrocklab.com wrote:
Hello, every one. Is it possible to merge elrepo.org contribute to centos main repository?elrepo.org contribute the latest hardware driver and latest kernel for centos.Using it for a longtime, just want to know if it possible to got it merged to centos main repository. What we expected? The latest kernel cotains more optimizer for filesystem driver. such as XFS.
Short answer? No.
Long answer:
- The base repository design will not change. These packages could be
accepted into a SIG or variant build, but they will never be in base.
- Elrepo is an entirely separate project that we have no control over.
It's entirely up to them to decide if they want to go this route. We could certainly welcome them, but it's not our decision to make.
Since ELRepo make a point of being independent and working with all RHEL clones and RHEL itself, I do not think they really fit in the CentOS space.
T
On Tue, Feb 25, 2014 at 9:21 AM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
Is it possible to merge elrepo.org contribute to centos main repository?elrepo.org contribute the latest hardware driver and latest kernel for centos.Using it for a longtime, just want to know if it possible to got it merged to centos main repository. What we expected? The latest kernel cotains more optimizer for filesystem driver. such as XFS.
Short answer? No.
Long answer:
- The base repository design will not change. These packages could be
accepted into a SIG or variant build, but they will never be in base.
- Elrepo is an entirely separate project that we have no control over.
It's entirely up to them to decide if they want to go this route. We could certainly welcome them, but it's not our decision to make.
Since ELRepo make a point of being independent and working with all RHEL clones and RHEL itself, I do not think they really fit in the CentOS space.
On the other hand it would save a step for many users and lower the learning curve for anyone new to include the release-rpm for the elrepo and EPEL repositories in the distribution - even if they were disabled by default.
On 02/25/2014 04:10 PM, Les Mikesell wrote:
On the other hand it would save a step for many users and lower the learning curve for anyone new to include the release-rpm for the elrepo and EPEL repositories in the distribution - even if they were disabled by default.
As Jim already mentioned - the point of consideration for such efforts would be on the repository people in that effort - we would welcome pretty much any reasonable suggestion from their end. For ELRepo and what they do - I dont see any reason why they could not atleast use the infra and distribution mechanism that we have here and work out of the same codebase contents.
Pretty much the same as any other repo might.
- KB
On Tue, Feb 25, 2014 at 8:13 AM, Karanbir Singh mail-lists@karan.org wrote:
On 02/25/2014 04:10 PM, Les Mikesell wrote:
On the other hand it would save a step for many users and lower the learning curve for anyone new to include the release-rpm for the elrepo and EPEL repositories in the distribution - even if they were disabled by default.
As Jim already mentioned - the point of consideration for such efforts would be on the repository people in that effort - we would welcome pretty much any reasonable suggestion from their end. For ELRepo and what they do - I dont see any reason why they could not atleast use the infra and distribution mechanism that we have here and work out of the same codebase contents.
What Les meant was the inclusion of the xxx-release packages in the distribution. Those package would not be installed by default, but will be just one yum command away:
yum install elrepo-release
or
yum install epel-release
Scientific Linux has them and that makes it easy for users to install those repos if/when they want them.
Akemi
On Tue, Feb 25, 2014 at 3:32 PM, Akemi Yagi amyagi@gmail.com wrote:
On Tue, Feb 25, 2014 at 8:13 AM, Karanbir Singh mail-lists@karan.org wrote:
On 02/25/2014 04:10 PM, Les Mikesell wrote:
On the other hand it would save a step for many users and lower the learning curve for anyone new to include the release-rpm for the elrepo and EPEL repositories in the distribution - even if they were disabled by default.
As Jim already mentioned - the point of consideration for such efforts would be on the repository people in that effort - we would welcome pretty much any reasonable suggestion from their end. For ELRepo and what they do - I dont see any reason why they could not atleast use the infra and distribution mechanism that we have here and work out of the same codebase contents.
What Les meant was the inclusion of the xxx-release packages in the distribution. Those package would not be installed by default, but will be just one yum command away:
yum install elrepo-release
or
yum install epel-release
Scientific Linux has them and that makes it easy for users to install those repos if/when they want them.
Yes - or even have them installed by default. It still doesn't get you a full match for the packages you could install in, say, Ubuntu without having to go search for which repositories have packages you need and are not likely to break your system, but it would help.
On 02/25/2014 03:32 PM, Akemi Yagi wrote:
What Les meant was the inclusion of the xxx-release packages in the distribution. Those package would not be installed by default, but will be just one yum command away:
yum install elrepo-release
or
yum install epel-release
Scientific Linux has them and that makes it easy for users to install those repos if/when they want them.
In the past, we had specifically avoided doing this for a few reasons:
1. We didn't want to be accused of playing favorites with 3rd party repos
2. We didn't want the expectation of support ("I didn't add anything to the default centos, I just yum-installed it!")
3. We didn't want to ship code that wasn't built/signed by us.
Given the new structure, it may be worth having this conversation again. Thoughts from the community?
On 02/26/2014 02:13 AM, Jim Perrin wrote:
On 02/25/2014 03:32 PM, Akemi Yagi wrote:
What Les meant was the inclusion of the xxx-release packages in the distribution. Those package would not be installed by default, but will be just one yum command away:
yum install elrepo-release
or
yum install epel-release
Scientific Linux has them and that makes it easy for users to install those repos if/when they want them.
In the past, we had specifically avoided doing this for a few reasons:
We didn't want to be accused of playing favorites with 3rd party repos
We didn't want the expectation of support ("I didn't add anything to
the default centos, I just yum-installed it!")
- We didn't want to ship code that wasn't built/signed by us.
Given the new structure, it may be worth having this conversation again. Thoughts from the community?
I am as much in favor of including epel- and elrepo-release as I could be. They are reputable and widely used and making them easier available for end users instead of having people sent to look for instructions would definitely make CentOS more user friendly. However by default I would keep them disabled.
I'd even like to see them included in the full-DVD, maybe in a separate /extras directory
On 02/26/2014 09:37 AM, Manuel Wolfshant wrote:
I am as much in favor of including epel- and elrepo-release as I could be. They are reputable and widely used and making them easier available for end users
but you need to quantify that - then make it possible for people to target that level to get included.
and this needs to include the quality and tests of quality around what is shipped out.
On 02/26/2014 11:54 AM, Karanbir Singh wrote:
On 02/26/2014 09:37 AM, Manuel Wolfshant wrote:
I am as much in favor of including epel- and elrepo-release as I could be. They are reputable and widely used and making them easier available for end users
but you need to quantify that - then make it possible for people to target that level to get included.
We do not vouch for their quality and we will not support what they ship. We will just make easier for people to use them
and this needs to include the quality and tests of quality around what is shipped out.
No it does not. See the reasons above,
On 02/26/2014 09:59 AM, Manuel Wolfshant wrote:
We do not vouch for their quality and we will not support what they ship. We will just make easier for people to use them
you are missing the point - what are we making easier ? there are more than 100 repos out there, which ones are we going to add and why and then at that point what do the others need to do in order to also get included ?
- KB
On 02/26/2014 12:55 PM, Karanbir Singh wrote:
On 02/26/2014 09:59 AM, Manuel Wolfshant wrote:
We do not vouch for their quality and we will not support what they ship. We will just make easier for people to use them
you are missing the point - what are we making easier ?
The life of those who want to use packages not provided by stock centos. Each and every day on the IRC ( and in the forums, afaik ) there are people who ask for packages available only in 3rd party repos and they get sent to the wiki page related to 3rd party repos
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape. The list can be as long as one desires but from my point of view it boils down to a) additional hardware support b) multimedia not supported out of the box c) applications not existing in the core repos d) newer versions of the apps that are already included I would start by targeting the first 3 classes above. And for a) there is exactly one provider, elrepo. Who does a very good job, from my point of view. In terms of additional hardware support the only choices are the centosplus kernel and elrepo, which covers a rather large target via their kmods
and why
Because people would reach for them anyway , via http://wiki.centos.org/AdditionalResources/Repositories or via more-or-less good advices received from other sources. Instead of forcing them to read in fast speed that page and then in the same fast speed another page specific to the repo just to end doing wget whatever-release.rpm && yum localinstall whatever-release.rpm we give them a hand and replace all the mumbo jumbo with "yum install whatever-release". No matter how much we like pointing people to documentation, experience in #centos has shown that most of them will ignore anything not related to the very exact instructions on how to install the repo. And if you want to know why ELRepo and EPEL and not others: because these two ( plus IUS ) are the ones most frequently recommended by those of us who offer support via IRC. Leaving aside that SL includes references to these two repos for quite some time , this mere thread is a proof that there is a need that should be addressed.
and then at that point what do the others need to do in order to also get included ?
For a start, they should not blindly replace core packages. Second they should have | earned a good reputation. And both repositories that have been suggested fit these bills. Their reputation was earned over the years and they ship packages which people need/use, not just fancy stuff included just because it could be done.
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
On 02/26/2014 01:31 PM, Karanbir Singh wrote:
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
And short of counting the "pro" and "against" expressed via mailing list / forum/ chat how do you suggest to do that ?
On 02/26/2014 05:31 AM, Karanbir Singh wrote:
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
Lets just get specific here an explain why this can be sticky.
OK, so repoforge and EPEL do not play nicely together. We would, in my opinion, only be able to include one or the other release file in our extras repo as installing both produces broken yum installs of packages.
That is but one example.
I personally would have no real problem with both an epel-release and an elrepo-release RPM in CentOS Extras ... but then why not also nux-desktop or remi or repoforge? Those will not all work together, who do we leave out?
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay fine, that is their choice, they are independent. If you want them in CentOS, tell them on their lists to join as a CentOS SIG.
Even IF we included these repos and they were disabled, the people who can not find how to do one yum install command in the wiki would also not be able to enable the .repo file without looking at the same wiki page or ask on IRC to get instructions. It is the same amount of time to edit a .repo file and enable it as to do yum install some-release-file.rpm. If we are going to put the release files in, then we need to have at least the most common options enabled.
So, which do we add in and who gets left out ... personally to be fair, I think they should all be left out instead of picking favorites. I would also certainly not want to enable anything by default that replaced core packages.
On 02/26/2014 01:53 PM, Johnny Hughes wrote:
On 02/26/2014 05:31 AM, Karanbir Singh wrote:
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
Lets just get specific here an explain why this can be sticky.
OK, so repoforge and EPEL do not play nicely together. We would, in my opinion, only be able to include one or the other release file in our extras repo as installing both produces broken yum installs of packages.
That is but one example.
I personally would have no real problem with both an epel-release and an elrepo-release RPM in CentOS Extras ... but then why not also nux-desktop or remi or repoforge? Those will not all work together, who do we leave out?
I've already answered these questions in a previous message
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay fine, that is their choice, they are independent. If you want them in CentOS, tell them on their lists to join as a CentOS SIG.
So there exists a "if it's not a CentOS SIG , we do not include references to them even if people still need to use them " policy. Fine, why did you not say so from the beginning ? It would have shorten the thread significantly
Even IF we included these repos and they were disabled, the people who can not find how to do one yum install command in the wiki would also not be able to enable the .repo file without looking at the same wiki page or ask on IRC to get instructions. It is the same amount of time to edit a .repo file and enable it as to do yum install
Experience has shown that there is a huge difference between " ask google about a package, look for a repo, try to find out how to enable said repo , download some-release-file.rpm file yum install some-release-file.rpm " and "yum install some-release-file.rpm " Not to mention that very few people make use of yum-config-manager, despite its usefulness.
some-release-file.rpm. If we are going to put the release files in, then we need to have at least the most common options enabled.
I beg to differ. All we have to do is to include the package and teach people how to yum install it. It's far easier than asking them to look for a download link, download and install.
So, which do we add in and who gets left out
As I have said, I have already answered these questions
... personally to be fair, I think they should all be left out instead of picking favorites. I would also certainly not want to enable anything by default that replaced core packages.
Which is why the list was restricted to these 2 repos only and did not include IUS for instance - even if IUS is one of the most polite 3rd party repos
On 02/26/2014 01:25 PM, Manuel Wolfshant wrote:
On 02/26/2014 01:53 PM, Johnny Hughes wrote:
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay fine, that is their choice, they are independent. If you want them in CentOS, tell them on their lists to join as a CentOS SIG.
So there exists a "if it's not a CentOS SIG , we do not include references to them even if people still need to use them " policy. Fine, why did you not say so from the beginning ? It would have shorten the thread significantly
I have hit the same obstacle of "nothing will be changed" when I asked for setting up priority infrastructure. I was debating with Core guys for full 2 weeks before I was told snowflake has more chance in hell then CentOS has chance to change.
My understanding is that nothing more then allowing Cloud people to work in one/several SIG's will EVER going to change in CentOS, so there is no point in even trying. Especially not for newbies/Desktops. CentOS distro will remain user-unfriendly until Sun turns off, and as consequence it will remain a distro of choice for RHEL admins and no one else. Sad but fact of life. It has me thinking that one option is to ditch actual CentOS and use something CentOS like, maybe SL or Russian ROSA, so if I help someone I do not have to spill blood and waste time all the time. I already lost many business opportunities by standing my ground in "I only use CentOS", so I might even think about learning Debian way and cover both Desktop and Server users with one knowledge and expertise.
Only way to make things easier for newbies/Desktop use is to create repository that will have release info on all third party repositories, so you give newbies instruction like
yum install http://<link to single release file> yum install epel-release yum install elrepo-release etc.
On Wed, Feb 26, 2014 at 7:31 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
My understanding is that nothing more then allowing Cloud people to work in one/several SIG's will EVER going to change in CentOS, so there is no point in even trying. Especially not for newbies/Desktops. CentOS distro will remain user-unfriendly until Sun turns off, and as consequence it will remain a distro of choice for RHEL admins and no one else. Sad but fact of life. It has me thinking that one option is to ditch actual CentOS and use something CentOS like, maybe SL or Russian ROSA, so if I help someone I do not have to spill blood and waste time all the time. I already lost many business opportunities by standing my ground in "I only use CentOS", so I might even think about learning Debian way and cover both Desktop and Server users with one knowledge and expertise.
You are going to want packages on a desktop for media playing, etc. that won't ever be in EPEL because of policies that can't change. So you might as well stat with ubuntu or mint.
Only way to make things easier for newbies/Desktop use is to create repository that will have release info on all third party repositories, so you give newbies instruction like
yum install http://<link to single release file> yum install epel-release yum install elrepo-release etc.
But here is the problem. If you use more than epel and elrepo you have no assurance that the 3rd 3rd party repo will stay coordinated with epel (which you'll almost certainly need). The more you add, the more chances there are for duplication of package names that aren't really the same packages or build. And eventually you'll run into a conflict in updates or the update will pull in a version of something with surprising differences - and not having that kind of breakage is the main reason to start with CentOS in the first place. If you were advising someone else how to set up their first Centos box, think about how long that conversation has to be, and how strange it all seems that the repositories set up to help people do not stay coordinated with each other and thus are likely to eventually cause trouble. Even ones that don't replace core packages don't track each other.
On 02/26/2014 02:55 PM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 7:31 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
My understanding is that nothing more then allowing Cloud people to work in one/several SIG's will EVER going to change in CentOS, so there is no point in even trying. Especially not for newbies/Desktops. CentOS distro will remain user-unfriendly until Sun turns off, and as consequence it will remain a distro of choice for RHEL admins and no one else. Sad but fact of life. It has me thinking that one option is to ditch actual CentOS and use something CentOS like, maybe SL or Russian ROSA, so if I help someone I do not have to spill blood and waste time all the time. I already lost many business opportunities by standing my ground in "I only use CentOS", so I might even think about learning Debian way and cover both Desktop and Server users with one knowledge and expertise.
You are going to want packages on a desktop for media playing, etc. that won't ever be in EPEL because of policies that can't change. So you might as well stat with ubuntu or mint.
Only way to make things easier for newbies/Desktop use is to create repository that will have release info on all third party repositories, so you give newbies instruction like
yum install http://<link to single release file> yum install epel-release yum install elrepo-release etc.
But here is the problem. If you use more than epel and elrepo you have no assurance that the 3rd 3rd party repo will stay coordinated with epel (which you'll almost certainly need). The more you add, the more chances there are for duplication of package names that aren't really the same packages or build. And eventually you'll run into a conflict in updates or the update will pull in a version of something with surprising differences - and not having that kind of breakage is the main reason to start with CentOS in the first place. If you were advising someone else how to set up their first Centos box, think about how long that conversation has to be, and how strange it all seems that the repositories set up to help people do not stay coordinated with each other and thus are likely to eventually cause trouble. Even ones that don't replace core packages don't track each other.
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Ultimately, responsibility lies on user. He is the owner of the system, and he will do what ever needs to be done. And since CentOS/RHEL does not provide MANY things (EPEL is 2 TIMES LARGER then Base + Updates repositories, and elrepo has 260 packages so at least 150 distinct drivers NEEDED by community).
So when one stupid newbie created blog entry explaining that CentOS does not have that package, so you need to recompile it, and gives you step-by-step howto, something is wrong. But when there is MORE such pages/blogs then "install it from 3rd party repository we wish not to name so there are no favorites...", then you have a HUGE problem. And solution is to REDUCE the number of problematic blogs/pages, not increase them doing absolutely nothing. "Prime directive" (Star Trek reference) is all excellent and shiny, but does not solve people getting burned anyway, and teaching others the wrong way in the process.
By the way, RepoForge is practically dead in the water so no need using it as EPEL vs Repoforge argument. If you were to create a poll on forums (2-3 weeks of announcement in advance would be enough to rally all for and against) where you would ask:
1) Do you agree that release packages for only EPEL and ElRepo repositories are provided, but not other repositories, I am guessing 80-90% will vote yes, and you will have community approval as a basis for any question other repositories might raise.
I would be happy with something just resembling the CentOS name (DentOS. PentOS, ...), but on the same resources as CentOS (either using CentOS packages as a base or rebuilding it under another brand while building CentOS packages) so there is newbie-friendly version that allows 3rd party repositories. And I am guessing that this approach would mean most people would choose this enhanced version of CentOS over original CentOS, exactly because of out-of-the-box experience.
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
On Wed, Feb 26, 2014 at 04:33:55PM +0100, Ljubomir Ljubojevic wrote:
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
Or you could point people to the documentation and let them install the -release files themselves like has been done for years.
This is really getting ridiculous. If the bar of entry is so high that merely installing a 3rd-party -release file is too complicated or difficult people might care to revisit their career path. The distro has no real need to provide these -release files and the potential problems with doing so outweigh any benefits.
John
On Wed, Feb 26, 2014 at 9:33 AM, Ljubomir Ljubojevic centos@plnet.rs wrote:
And eventually you'll run into a conflict in updates or the update will pull in a version of something with surprising differences - and not having that kind of breakage is the main reason to start with CentOS in the first place. If you were advising someone else how to set up their first Centos box, think about how long that conversation has to be, and how strange it all seems that the repositories set up to help people do not stay coordinated with each other and thus are likely to eventually cause trouble. Even ones that don't replace core packages don't track each other.
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Yes, very often it is. If you build under /usr/local as most source packages do, it won't break your system updates. If instead, you get a yum conflict and don't know how to fix it, you'll never get any security fixes again.
Ultimately, responsibility lies on user. He is the owner of the system, and he will do what ever needs to be done. And since CentOS/RHEL does not provide MANY things (EPEL is 2 TIMES LARGER then Base + Updates repositories, and elrepo has 260 packages so at least 150 distinct drivers NEEDED by community).
Yes, you understand the problem. RHEL/CentOS are not suitable for casual users who don't want to dedicate their lives to tracking where to find packages and which repositories play well with others. Everyone here talking about it is a professional who does that sort of thing, but frankly there are better things to do.
So when one stupid newbie created blog entry explaining that CentOS does not have that package, so you need to recompile it, and gives you step-by-step howto, something is wrong.
No, that is exactly the state of affairs that you should expect from the current situation.
But when there is MORE such pages/blogs then "install it from 3rd party repository we wish not to name so there are no favorites...", then you have a HUGE problem. And solution is to REDUCE the number of problematic blogs/pages, not increase them doing absolutely nothing. "Prime directive" (Star Trek reference) is all excellent and shiny, but does not solve people getting burned anyway, and teaching others the wrong way in the process.
The blog pages are an effect, not the cause of the situation. The cause is that EPEL policy keeps out many packages that are needed - and that's not going to change unless they change locations/ownership or US law changes. Other repos don't stay strictly coordinated with EPEL, and from historical accounts that seems to be impossible.
- Do you agree that release packages for only EPEL and ElRepo
repositories are provided, but not other repositories, I am guessing 80-90% will vote yes, and you will have community approval as a basis for any question other repositories might raise.
Yes, unless there is some assurance of a policy in other repos that they will remain coordinated with those 2 in addition to not replacing base packages. Making yum stop getting security updates is about the worst thing that can happen to a box.
I would be happy with something just resembling the CentOS name (DentOS. PentOS, ...), but on the same resources as CentOS (either using CentOS packages as a base or rebuilding it under another brand while building CentOS packages) so there is newbie-friendly version that allows 3rd party repositories. And I am guessing that this approach would mean most people would choose this enhanced version of CentOS over original CentOS, exactly because of out-of-the-box experience.
The problem isn't the base contents. It is the lack of strict coordination among 3rd party repos. Either a single repo needs to include all of what EPEL provides plus the things their policy excludes (probably not permitted) or the other repos need to stay strictly coordinated and conflict free (probably not possible).
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
This is no equivalent for the coordination among the additional repositories that you can enable for debian/Ubuntu. And there is no 'proper' way to do the equivalent of installing those additional packages under RHEL/CentOS because there can be no expectation that wherever you'd suggest getting them will not cause update conflicts.
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
I haven't seen any issues that would solve by itself.
On 02/26/2014 09:33 AM, Ljubomir Ljubojevic wrote:
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Not one single person has ever said that in this discussion. That's not even what this is about. This is about including packages in the CORE (yes, extras is enabled by default) distribution.
If a sig wants to create a 'centos-enhanced' distribution and pull these repos in, that's entirely fine. I don't have a single problem with that and would happily support it. That's entirely the point of the SIG/variant framework. However we've always been protective of the core distribution, and that's one of the reasons it's been successful.
So when one stupid newbie created blog entry explaining that CentOS does not have that package, so you need to recompile it, and gives you step-by-step howto, something is wrong. But when there is MORE such pages/blogs then "install it from 3rd party repository we wish not to name so there are no favorites...", then you have a HUGE problem. And solution is to REDUCE the number of problematic blogs/pages, not increase them doing absolutely nothing. "Prime directive" (Star Trek reference) is all excellent and shiny, but does not solve people getting burned anyway, and teaching others the wrong way in the process.
This issue isn't going to go away just because packages are available. There are plenty of "how-to" instructions for rebuilding source for packages that exist in base. zlib being the common example.
By the way, RepoForge is practically dead in the water so no need using it as EPEL vs Repoforge argument. If you were to create a poll on forums (2-3 weeks of announcement in advance would be enough to rally all for and against) where you would ask:
Fine substitute any other repository name out there. There are dozens to choose from.
- Do you agree that release packages for only EPEL and ElRepo
repositories are provided, but not other repositories, I am guessing 80-90% will vote yes, and you will have community approval as a basis for any question other repositories might raise.
Still missing the point. It's not a popularity contest. Yes, those two win hands down. It's about establishing a baseline or metric so that OTHER repos might work toward gaining that same level of acceptance/trust, AND making sure we don't allow conflicting repos by default, thus breaking yum update.
I would be happy with something just resembling the CentOS name (DentOS. PentOS, ...), but on the same resources as CentOS (either using CentOS packages as a base or rebuilding it under another brand while building CentOS packages) so there is newbie-friendly version that allows 3rd party repositories. And I am guessing that this approach would mean most people would choose this enhanced version of CentOS over original CentOS, exactly because of out-of-the-box experience.
Again, this is EXACTLY the point of the SIG/variant concept. I challenged you before to do this exact thing for a desktop sig.
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
Dunno about a video, but I am working on a wiki page that deals with the various command translations ( apt-get install foo -> yum install foo).
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
We have been thinking about this, at least with EPEL. There are pitfalls with doing this as well. Control is not absolute, as we do not own EPEL. If we duplicate it, and adjust a package then we're a fork and we're back to the same old interoperability discussion again depending on what's changed, versions, and/or build deps.
apropos: https://xkcd.com/927/
On Wed, Feb 26, 2014 at 10:20 AM, Jim Perrin jperrin@centos.org wrote:
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Not one single person has ever said that in this discussion. That's not even what this is about. This is about including packages in the CORE (yes, extras is enabled by default) distribution.
I say that. And it is about the problem of easily creating yum conflicts with a mix of repositories. I think that problem deserves some effort to fix.
If a sig wants to create a 'centos-enhanced' distribution and pull these repos in, that's entirely fine. I don't have a single problem with that and would happily support it. That's entirely the point of the SIG/variant framework. However we've always been protective of the core distribution, and that's one of the reasons it's been successful.
The base portion isn't even part of the problem, though.
By the way, RepoForge is practically dead in the water so no need using it as EPEL vs Repoforge argument. If you were to create a poll on forums (2-3 weeks of announcement in advance would be enough to rally all for and against) where you would ask:
Fine substitute any other repository name out there. There are dozens to choose from.
Hence the problem. Which set will provide the package a new user will almost certainly need and never break their update? How much time would it take to explain this correctly to a new user? How much damage will it do when yum stops updating?
Still missing the point. It's not a popularity contest. Yes, those two win hands down. It's about establishing a baseline or metric so that OTHER repos might work toward gaining that same level of acceptance/trust, AND making sure we don't allow conflicting repos by default, thus breaking yum update.
Would it be possible to automate checking the entire contents of multiple repositories? That is, without actually merging the repos, check that there are no missing/conflicting dependencies or contents (probably with EPEL as a requirement), no duplicate package names with differing contents, or anything else that might either break yum or cause surprises from replaced packages. Maybe just having an objective validator and some repo manager cooperation would fix things.
Again, this is EXACTLY the point of the SIG/variant concept. I challenged you before to do this exact thing for a desktop sig.
Would/could, the permissible contents be different for a SIG than for EPEL? Could a SIG variant include, say, vlc or equivalent media players?
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
Dunno about a video, but I am working on a wiki page that deals with the various command translations ( apt-get install foo -> yum install foo).
And what are you going to suggest as a replacement for the repositories Ubuntu would let you enable?
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
We have been thinking about this, at least with EPEL. There are pitfalls with doing this as well. Control is not absolute, as we do not own EPEL. If we duplicate it, and adjust a package then we're a fork and we're back to the same old interoperability discussion again depending on what's changed, versions, and/or build deps.
It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that.
On 02/26/2014 10:47 AM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 10:20 AM, Jim Perrin jperrin@centos.org wrote:
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Not one single person has ever said that in this discussion. That's not even what this is about. This is about including packages in the CORE (yes, extras is enabled by default) distribution.
I say that. And it is about the problem of easily creating yum conflicts with a mix of repositories. I think that problem deserves some effort to fix.
If a sig wants to create a 'centos-enhanced' distribution and pull these repos in, that's entirely fine. I don't have a single problem with that and would happily support it. That's entirely the point of the SIG/variant framework. However we've always been protective of the core distribution, and that's one of the reasons it's been successful.
The base portion isn't even part of the problem, though.
By the way, RepoForge is practically dead in the water so no need using it as EPEL vs Repoforge argument. If you were to create a poll on forums (2-3 weeks of announcement in advance would be enough to rally all for and against) where you would ask:
Fine substitute any other repository name out there. There are dozens to choose from.
Hence the problem. Which set will provide the package a new user will almost certainly need and never break their update? How much time would it take to explain this correctly to a new user? How much damage will it do when yum stops updating?
Still missing the point. It's not a popularity contest. Yes, those two win hands down. It's about establishing a baseline or metric so that OTHER repos might work toward gaining that same level of acceptance/trust, AND making sure we don't allow conflicting repos by default, thus breaking yum update.
Would it be possible to automate checking the entire contents of multiple repositories? That is, without actually merging the repos, check that there are no missing/conflicting dependencies or contents (probably with EPEL as a requirement), no duplicate package names with differing contents, or anything else that might either break yum or cause surprises from replaced packages. Maybe just having an objective validator and some repo manager cooperation would fix things.
Again, this is EXACTLY the point of the SIG/variant concept. I challenged you before to do this exact thing for a desktop sig.
Would/could, the permissible contents be different for a SIG than for EPEL? Could a SIG variant include, say, vlc or equivalent media players?
It has to be something that we can legally distribute from a US law perspective. If it fits that criteria, then yes.
Maybe even "What is a proper way to do things" video that explains differences to other distro's for users that are coming from Ubuntu/Debian/Mint could help such transitions.
Dunno about a video, but I am working on a wiki page that deals with the various command translations ( apt-get install foo -> yum install foo).
And what are you going to suggest as a replacement for the repositories Ubuntu would let you enable?
The same repositories we already list via the wiki.
Also worth thinking about is rebuilding EPEL and ElRepo packages inside CentOS build system, so control is absolute that it will not mess up anything.
We have been thinking about this, at least with EPEL. There are pitfalls with doing this as well. Control is not absolute, as we do not own EPEL. If we duplicate it, and adjust a package then we're a fork and we're back to the same old interoperability discussion again depending on what's changed, versions, and/or build deps.
It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that.
We don't have the same restrictions that EPEL does, so the barrier to entry should be lower.
On Wed, Feb 26, 2014 at 11:48 AM, Jim Perrin jperrin@centos.org wrote:
Would/could, the permissible contents be different for a SIG than for EPEL? Could a SIG variant include, say, vlc or equivalent media players?
It has to be something that we can legally distribute from a US law perspective. If it fits that criteria, then yes.
But media players typically aren't. So then no. Unless you can cooperate with outside entities.
Dunno about a video, but I am working on a wiki page that deals with the various command translations ( apt-get install foo -> yum install foo).
And what are you going to suggest as a replacement for the repositories Ubuntu would let you enable?
The same repositories we already list via the wiki.
How can you recommend that, knowing that following your advice is very likely to end up preventing yum from getting security updates over much of the system's expected long lifetime?
It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that.
We don't have the same restrictions that EPEL does, so the barrier to entry should be lower.
I'm not convinced. I think some automated vetting of combinations of independent repos would be a much more complete solution. That way you could recommend a set of repos or include their -release rpms in the base disto without the expectation of future breakage as the result. And the usefulness would apply to RHEL/SL or anything built on the same base packages.
On 02/26/2014 07:34 PM, Les Mikesell wrote:
We don't have the same restrictions that EPEL does, so the barrier to
entry should be lower.
I'm not convinced. I think some automated vetting of combinations of independent repos would be a much more complete solution. That way you could recommend a set of repos or include their -release rpms in the base disto without the expectation of future breakage as the result. And the usefulness would apply to RHEL/SL or anything built on the same base packages.
NOT "base distro"!, additional repositories! Base repo/packages come only from RHEL source rpms.
On Wed, Feb 26, 2014 at 12:52 PM, Ljubomir Ljubojevic centos@plnet.rs wrote:
We don't have the same restrictions that EPEL does, so the barrier to
entry should be lower.
I'm not convinced. I think some automated vetting of combinations of independent repos would be a much more complete solution. That way you could recommend a set of repos or include their -release rpms in the base disto without the expectation of future breakage as the result. And the usefulness would apply to RHEL/SL or anything built on the same base packages.
NOT "base distro"!, additional repositories! Base repo/packages come only from RHEL source rpms.
There are really two different scenarios. You can sort-of assume that base, EPEL, elrepo, and cento-extras are all necessary in common situations and all make an effort not to step on each others' toes, so that doesn't need much consideration. One scenario that does, is where you need a package these repos don't include and that package itself doesn't overwrite anything the repos above provide. OpenNMS would be a safe example. Ocsinventory-server is more problematic. It would work without replacing packages, but the remi repo containing it will offer to stomp on your msyql, php and a bunch of other stuff. The other scenario is where the functionality you need only comes from newer/replaced base packages or libraries. The latter situation is so much harder to handle correctly that it probably shouldn't be lumped together with the simpler 'additional package' case which itself is already harder than it should be because the repositories often mix them with things that do cause conflicts.
On 02/26/2014 06:48 PM, Jim Perrin wrote:
On 02/26/2014 10:47 AM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 10:20 AM, Jim Perrin jperrin@centos.org wrote:
Is it better to have users COMPILE FROM SOURCE???? Because they f***ing DO!
Not one single person has ever said that in this discussion. That's not even what this is about. This is about including packages in the CORE (yes, extras is enabled by default) distribution.
I say that. And it is about the problem of easily creating yum conflicts with a mix of repositories. I think that problem deserves some effort to fix.
If a sig wants to create a 'centos-enhanced' distribution and pull these repos in, that's entirely fine. I don't have a single problem with that and would happily support it. That's entirely the point of the SIG/variant framework. However we've always been protective of the core distribution, and that's one of the reasons it's been successful.
If whole (current) community decides to vote, and they choose EPEL to standardize on, most repositories will accept it, because most of them anyway reference EPEL or require it for their repositories. At least for parts of repositories that will not replace anything in base/epel.
For those that need to change base/epel packages, you are NOT going to allow/support ANYWAY. So if they agree to play well with EPEL (if community chooses that EPEL release file is provided), then those rare occasions where something is wrong can be fairly easy to fix. There is MUCH better chance of repositories obeying the rules then if everything is "in the wild". Show them prize of recognition and acceptance if they obey rules, and many will follow them.
The base portion isn't even part of the problem, though.
By the way, RepoForge is practically dead in the water so no need using it as EPEL vs Repoforge argument. If you were to create a poll on forums (2-3 weeks of announcement in advance would be enough to rally all for and against) where you would ask:
Fine substitute any other repository name out there. There are dozens to choose from.
Not at all. Only EPEL and Elrepo are so essential that I do not know a good admin that does not use them on at least one CentOS system, especially for Desktop/Workstation use, or on unsupported hardware like laptops.
Hence the problem. Which set will provide the package a new user will almost certainly need and never break their update? How much time would it take to explain this correctly to a new user? How much damage will it do when yum stops updating?
Still missing the point. It's not a popularity contest. Yes, those two win hands down. It's about establishing a baseline or metric so that OTHER repos might work toward gaining that same level of acceptance/trust, AND making sure we don't allow conflicting repos by default, thus breaking yum update.
Would it be possible to automate checking the entire contents of multiple repositories? That is, without actually merging the repos, check that there are no missing/conflicting dependencies or contents (probably with EPEL as a requirement), no duplicate package names with differing contents, or anything else that might either break yum or cause surprises from replaced packages. Maybe just having an objective validator and some repo manager cooperation would fix things.
Again, this is EXACTLY the point of the SIG/variant concept. I challenged you before to do this exact thing for a desktop sig.
Would/could, the permissible contents be different for a SIG than for EPEL? Could a SIG variant include, say, vlc or equivalent media players?
It has to be something that we can legally distribute from a US law perspective. If it fits that criteria, then yes.
If good framework is established (3rd party repository wise), then that stuff can be in some other repository. But in order to do so, there has to be easy to manage repository hierarchy, without too much messing with yum config files.
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
<snip>
On 02/26/2014 07:50 PM, Ljubomir Ljubojevic wrote:
Not at all. Only EPEL and Elrepo are so essential that I do not know a good admin that does not use them on at least one CentOS system, especially for Desktop/Workstation use, or on unsupported hardware like laptops.
Here. Me. I have various system because of various reasons I can only install RHEL or CentOS. And this will not change.
Still, I do use custom repositories with those systems which allow me to install software need on those system. And update that software.
Ain't that the whole point of having an Community Enterprise OS?
If good framework is established (3rd party repository wise), then that stuff can be in some other repository. But in order to do so, there has to be easy to manage repository hierarchy, without too much messing with yum config files.
We're talking about a seven line config file in /etc/yum.repos.d to add a new repository. And honestly, if I don't know what I'm doing the, it might be a good idea to not do it. Learning curve or not.
I have broken an awful lot of installations in my professional life by adding some repo to fix one thing and breaking ten other things. The luxury of doing some yum install <blabumm> comes at the price of understanding the complexity of solving the dependencies.
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
Maybe, just maybe, a Community Enterprise OS is just not the right choice for this? And maybe, just maybe, putting wings on a cow won't turn it into a proper bird.
Honestly, why would anybody try to turn something like RHEL 6 into a Desktop, with all those old kernel-stuff, the old libraries and all the fuss you have to cope with - and still end up with something that will not be able to run all the latest gimmicks with the complete set of bells and whistles?
On Wed, Feb 26, 2014 at 1:41 PM, Alexander Arlt centos@track5.de wrote:
If good framework is established (3rd party repository wise), then that stuff can be in some other repository. But in order to do so, there has to be easy to manage repository hierarchy, without too much messing with yum config files.
We're talking about a seven line config file in /etc/yum.repos.d to add a new repository. And honestly, if I don't know what I'm doing the, it might be a good idea to not do it. Learning curve or not.
The physical setup isn't a big deal. Knowing which are a good idea is pretty much impossible.
I have broken an awful lot of installations in my professional life by adding some repo to fix one thing and breaking ten other things. The luxury of doing some yum install <blabumm> comes at the price of understanding the complexity of solving the dependencies.
You can't really understand the future interactions of multiple uncoordinated things. But this is not something that every individual user should have gamble on independently or work out separate solutions for frequently-needed configurations.
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
Maybe, just maybe, a Community Enterprise OS is just not the right choice for this? And maybe, just maybe, putting wings on a cow won't turn it into a proper bird.
Maybe the US isn't the right location for it, or a US company the right management entity.
Honestly, why would anybody try to turn something like RHEL 6 into a Desktop, with all those old kernel-stuff, the old libraries and all the fuss you have to cope with - and still end up with something that will not be able to run all the latest gimmicks with the complete set of bells and whistles?
I think this discussion is more about RHEL7 and the future. And if it goes anywhere there should be one solution for coordinating technically non-conflicting packages that can't be hosted in the US and something different - on the order of RHEL software collections - for managing alternative/newer package versions that would otherwise conflict, but likewise with some central vetting to avoid conflicts.
On 02/26/2014 09:01 PM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 1:41 PM, Alexander Arlt centos@track5.de wrote:
You can't really understand the future interactions of multiple uncoordinated things.
To be honest, most of the time it's quite a challenge to understand the future interactions of multiple coordinated things. At least for me.
But this is not something that every individual user should have gamble on independently or work out separate solutions for frequently-needed configurations.
True. Is this solvable? I doubt so. What is a "frequently-needed" configuration? Again this would bring up Karanbir, saying this needs to be measurable. And he would be right. Just because something is posted repeatedly on the mailing list doesn't make it "frequently-needed".
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
Maybe, just maybe, a Community Enterprise OS is just not the right choice for this? And maybe, just maybe, putting wings on a cow won't turn it into a proper bird.
Maybe the US isn't the right location for it, or a US company the right management entity.
I don't think there are a lot of places on this planet where you can actually bring the wonderful world of multimedia together without breaking laws. We have paid a lot of tax-money to our rightful representatives to screw things up as good as possible.
Honestly, why would anybody try to turn something like RHEL 6 into a Desktop, with all those old kernel-stuff, the old libraries and all the fuss you have to cope with - and still end up with something that will not be able to run all the latest gimmicks with the complete set of bells and whistles?
I think this discussion is more about RHEL7 and the future. And if it goes anywhere there should be one solution for coordinating technically non-conflicting packages that can't be hosted in the US and something different - on the order of RHEL software collections - for managing alternative/newer package versions that would otherwise conflict, but likewise with some central vetting to avoid conflicts.
Actually it's kinda hard for me to imagine a setup kinda legal/illegal-repos, which will not break each other, will be maintained with proper care - and will be enterprise stable. Because it still will be CentOS. If you put a tick somewhere in some checkbox and by that enable some whatever repository - when this goes south, it will most probably be CentOS to take the blame, not the external repo.
On Wed, Feb 26, 2014 at 4:35 PM, Alexander Arlt centos@track5.de wrote:
You can't really understand the future interactions of multiple uncoordinated things.
To be honest, most of the time it's quite a challenge to understand the future interactions of multiple coordinated things. At least for me.
So far, I haven't seen a lot of problems across EPEL/CentOS-*/elrepo, although I guess I haven't let the versions of backuppc in extras and epel fight it out on the same box. And I expect them to continue to make an effort to avoid conflicts except for EPEL not considering centos-extras to be 'upstream'. Maybe even that will change now.
But this is not something that every individual user should have gamble on independently or work out separate solutions for frequently-needed configurations.
True. Is this solvable? I doubt so. What is a "frequently-needed" configuration? Again this would bring up Karanbir, saying this needs to be measurable. And he would be right. Just because something is posted repeatedly on the mailing list doesn't make it "frequently-needed".
I don't claim to know all of the details of possible conflicts, but I think it is a reasonable topic for discussion as to whether it would be practical for a central automated test to determine the potential conflicts across multiple remote repositories. And if it is, then we could move on to how the repository managers and users could use that information to best advantage.
Maybe the US isn't the right location for it, or a US company the right management entity.
I don't think there are a lot of places on this planet where you can actually bring the wonderful world of multimedia together without breaking laws. We have paid a lot of tax-money to our rightful representatives to screw things up as good as possible.
The whole point of this discussion is about avoiding duplication of effort - starting with each user not having to sort out every possible conflict himself. In that light it seems to make sense to look toward the distributions that have already put some effort into sorting out how and where to distribute more packages in a coordinated way.
Actually it's kinda hard for me to imagine a setup kinda legal/illegal-repos, which will not break each other, will be maintained with proper care - and will be enterprise stable.
You don't have to imagine it. Other distributions are already doing that - with some room for argument about stability and their release cycles.
Because it still will be CentOS. If you put a tick somewhere in some checkbox and by that enable some whatever repository - when this goes south, it will most probably be CentOS to take the blame, not the external repo.
The point here is for it not to go south in the first place. Do you think leaving it as an exercise for newbies is really the best approach for that?
On 02/26/2014 08:41 PM, Alexander Arlt wrote:
On 02/26/2014 07:50 PM, Ljubomir Ljubojevic wrote:
Not at all. Only EPEL and Elrepo are so essential that I do not know a good admin that does not use them on at least one CentOS system, especially for Desktop/Workstation use, or on unsupported hardware like laptops.
Here. Me. I have various system because of various reasons I can only install RHEL or CentOS. And this will not change.
Still, I do use custom repositories with those systems which allow me to install software need on those system. And update that software.
Ain't that the whole point of having an Community Enterprise OS?
If good framework is established (3rd party repository wise), then that stuff can be in some other repository. But in order to do so, there has to be easy to manage repository hierarchy, without too much messing with yum config files.
We're talking about a seven line config file in /etc/yum.repos.d to add a new repository. And honestly, if I don't know what I'm doing the, it might be a good idea to not do it. Learning curve or not.
I wrote several e-mails about the topic of priorities. You might want to read them first before you assume you know what we are talking about. Threads are "Repository structures for SIG and variants in the future" (~Jan 13th 2014) and "Repositories in new ecosystem and Desktop version" (~Jan 10th 2014).
I have broken an awful lot of installations in my professional life by adding some repo to fix one thing and breaking ten other things. The luxury of doing some yum install <blabumm> comes at the price of understanding the complexity of solving the dependencies.
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
Maybe, just maybe, a Community Enterprise OS is just not the right choice for this? And maybe, just maybe, putting wings on a cow won't turn it into a proper bird.
It's not a question if it is possible, I already have full "Desktop" version of CentOS, I started with 5.3, (CentOS + 3rd party repositories = 22,846 packages available for 6.5) using priorities. And I am yet to have ANY problem regarding yum (due to priority hierarchy).
So as far as I am concerned, I am good, could not be better. Base is table, almost unchanged, I replaced only audio/video packages and Firefox/Thunderbird (maybe few other packages I can not remember). Only problem I have sometimes Skype crashes my GNOME, but that is due to Microsoft messing things up. I will be trying either newer or much older version to avoid problems. I do not crave after latest and greatest, so I like stable system like CentOS but with some apps in addition. If I use one distro for server, I want to use same one for Desktop, so I keep only repositories for single distro on my server/mirror.
The problem comes when someone asks how HE can do the same. Then I have to point him on my repository, explain how my repository script works, I need to keep release packages updated, etc., but I am out of free time to do so on the regular basis. So I just gave up helping people in getting stable but full desktop. I let them do what ever stupid thing they learn for them self, I let them manually download some stuff that does not have dedicated repositories.
Honestly, why would anybody try to turn something like RHEL 6 into a Desktop, with all those old kernel-stuff, the old libraries and all the fuss you have to cope with - and still end up with something that will not be able to run all the latest gimmicks with the complete set of bells and whistles?
STABILITY my friend, STABILITY. IT JUST WORKS! I can install my system and trust it to be operational after 10 years, with regular updates. This especially goes for small businesses or older web surfers that are tired of viruses so they get installed CentOS and they or someone else just updates their system without worry of thrashed system and reinstallation.
I can still install CentOS 5.x on older hardware and it will work like a charm, with support and bugfixes. It will not be EOL in 1-2 years, EOL policy covers full life-span of average PC hardware. After 10 years even poor people in Africa or India will get another PC, used one, that can run on CentOS 6.x until end of it's EOL, and on, and on, and on.
On 02/26/2014 09:35 PM, Ljubomir Ljubojevic wrote:
On 02/26/2014 08:41 PM, Alexander Arlt wrote:
On 02/26/2014 07:50 PM, Ljubomir Ljubojevic wrote:
Not at all. Only EPEL and Elrepo are so essential that I do not know a good admin that does not use them on at least one CentOS system, especially for Desktop/Workstation use, or on unsupported hardware like laptops.
Here. Me. I have various system because of various reasons I can only install RHEL or CentOS. And this will not change.
Still, I do use custom repositories with those systems which allow me to install software need on those system. And update that software.
Ain't that the whole point of having an Community Enterprise OS?
If good framework is established (3rd party repository wise), then that stuff can be in some other repository. But in order to do so, there has to be easy to manage repository hierarchy, without too much messing with yum config files.
We're talking about a seven line config file in /etc/yum.repos.d to add a new repository. And honestly, if I don't know what I'm doing the, it might be a good idea to not do it. Learning curve or not.
I wrote several e-mails about the topic of priorities. You might want to read them first before you assume you know what we are talking about. Threads are "Repository structures for SIG and variants in the future" (~Jan 13th 2014) and "Repositories in new ecosystem and Desktop version" (~Jan 10th 2014).
I didn't want to appear as if I'm fully aware of the whole discussion, I just jumped in because of the assumption "everybody is using EPEL and Elrepo".
Actually I followed the discussion you mentioned but I don't really think that a lot of CentOS-/RHEL-User really care about the Desktop-Ramblings. Still, of course, those are just my assumptions.
If I do have a look at the SIGs-Page of CentOS I still get the feeling, that quite a lot of CentOS-Users and -Devs also focus on other topics.
Maybe, just maybe, a Community Enterprise OS is just not the right choice for this? And maybe, just maybe, putting wings on a cow won't turn it into a proper bird.
It's not a question if it is possible, I already have full "Desktop" version of CentOS, I started with 5.3, (CentOS + 3rd party repositories = 22,846 packages available for 6.5) using priorities. And I am yet to have ANY problem regarding yum (due to priority hierarchy).
So as far as I am concerned, I am good, could not be better. Base is table, almost unchanged, I replaced only audio/video packages and Firefox/Thunderbird (maybe few other packages I can not remember). Only problem I have sometimes Skype crashes my GNOME, but that is due to Microsoft messing things up. I will be trying either newer or much older version to avoid problems. I do not crave after latest and greatest, so I like stable system like CentOS but with some apps in addition. If I use one distro for server, I want to use same one for Desktop, so I keep only repositories for single distro on my server/mirror.
So, you turned the cow into a bird. And you did this just because you want to have a single distribution. That's fine. It kinda feels weird, but if it's the way you want it, it's fine. But don't you think it would have been easier - and probably less nerve-wracking - to just use a more birdish-type of material?
The problem comes when someone asks how HE can do the same. Then I have to point him on my repository, explain how my repository script works, I need to keep release packages updated, etc., but I am out of free time to do so on the regular basis. So I just gave up helping people in getting stable but full desktop. I let them do what ever stupid thing they learn for them self, I let them manually download some stuff that does not have dedicated repositories.
Yes, basically you have built a repository for your special needs. And in my understanding this was - and is - the way the game was meant to be played by Red Hat.
Honestly, why would anybody try to turn something like RHEL 6 into a Desktop, with all those old kernel-stuff, the old libraries and all the fuss you have to cope with - and still end up with something that will not be able to run all the latest gimmicks with the complete set of bells and whistles?
STABILITY my friend, STABILITY. IT JUST WORKS! I can install my system and trust it to be operational after 10 years, with regular updates. This especially goes for small businesses or older web surfers that are tired of viruses so they get installed CentOS and they or someone else just updates their system without worry of thrashed system and reinstallation.
I'm not really getting the point of the Stability-thing if you have to do so much to turn the cow into a bird. Especially when reading the paragraphs above. If stability means your desktop being stable and not crashing - remove skype (there are a lot of other reasons for doing this besides stability) and be happy. Yet it still will not be 'stable' in the sense of enterprise-usage.
In my understanding the stability of CentOS is based on the stability of Red Hat Enterprise Linux. I never ever in my whole life had the need to install another kernel. But I also never ever in my whole life bought hardware not certified for Red Hat Enterprise Linux. I understand that not everybody else has the need for the compatibility of CentOS - I still don't understand why on earth they go through all the hassle to use it, if they can buy and use whatever they want.
Ain't that all the point about an enterprise distribution: that you have the support, the certifications, all the big-dollar-bling-bling? If you're messing around with all the upstream-provided stuff, elrepo-kernels and so on, you're already breaking the main (and most expensive) part of the enterprise thingy. And wasn't CentOS all about getting the enterprise-grade distribution cloned has close as possible?
Don't get me wrong, if you can find a majority for all your changes and if it proves to be worth it - I will be the first to thank you and welcome the changes. Unless your approved changes will break the enterprise in CentOS.
I can still install CentOS 5.x on older hardware and it will work like a charm, with support and bugfixes. It will not be EOL in 1-2 years, EOL policy covers full life-span of average PC hardware. After 10 years even poor people in Africa or India will get another PC, used one, that can run on CentOS 6.x until end of it's EOL, and on, and on, and on.
Forgive me but the life-span of RHEL or CentOS is not based on the lifetime of average PC hardware. I do have several machines and installations of RHEL 4 and we will have full support of hardware and software till Feb, 28th 2015. Probably longer. That's the E in RHEL and the ent in CentOS. Maybe I got that wrong and we now get back on the Entertainment the E and the ent was meant to mean from the beginning.
On Wed, Feb 26, 2014 at 4:02 PM, Alexander Arlt centos@track5.de wrote:
Actually I followed the discussion you mentioned but I don't really
think that a lot of CentOS-/RHEL-User really care about the Desktop-Ramblings. Still, of course, those are just my assumptions.
I think your assumption is right, but I also think that is a sorry state of affairs. Especially with Fedora leading the path and their focus on Desktop-ish things. If we have to put up with the issues that causes for servers, we should at least take advantage of what it adds for other uses.
So, you turned the cow into a bird. And you did this just because you want to have a single distribution. That's fine. It kinda feels weird, but if it's the way you want it, it's fine. But don't you think it would have been easier - and probably less nerve-wracking - to just use a more birdish-type of material?
Much of the point of free software is the fact that once something has been done once, any number of copies of it 'just work' for no extra cost. So, the missing piece here is just a reasonable way for someone else to duplicate the setup.
Yes, basically you have built a repository for your special needs. And in my understanding this was - and is - the way the game was meant to be played by Red Hat.
Red Hat just doesn't go there at all. If they don't distribute it, it is your problem.
Ain't that all the point about an enterprise distribution: that you have the support, the certifications, all the big-dollar-bling-bling?
No, that's really only relevant after something goes wrong. The point of it is the effort that goes into avoiding/fixing the things that go wrong. And the more people that run exactly the same code and report their bugs, sometimes with fixes, the better that turns out.
If you're messing around with all the upstream-provided stuff, elrepo-kernels and so on, you're already breaking the main (and most expensive) part of the enterprise thingy. And wasn't CentOS all about getting the enterprise-grade distribution cloned has close as possible?
Adding additional applications doesn't hurt the base. It is just better testing for it.
I can still install CentOS 5.x on older hardware and it will work like a charm, with support and bugfixes. It will not be EOL in 1-2 years, EOL policy covers full life-span of average PC hardware. After 10 years even poor people in Africa or India will get another PC, used one, that can run on CentOS 6.x until end of it's EOL, and on, and on, and on.
Forgive me but the life-span of RHEL or CentOS is not based on the lifetime of average PC hardware. I do have several machines and installations of RHEL 4 and we will have full support of hardware and software till Feb, 28th 2015. Probably longer. That's the E in RHEL and the ent in CentOS. Maybe I got that wrong and we now get back on the Entertainment the E and the ent was meant to mean from the beginning.
I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But that's all kind of irrelevant to what we should be preparing for after a new install of CentOS 7 and what to expect from it.
On 02/26/2014 11:26 PM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 4:02 PM, Alexander Arlt centos@track5.de wrote:
So, you turned the cow into a bird. And you did this just because you want to have a single distribution. That's fine. It kinda feels weird, but if it's the way you want it, it's fine. But don't you think it would have been easier - and probably less nerve-wracking - to just use a more birdish-type of material?
Much of the point of free software is the fact that once something has been done once, any number of copies of it 'just work' for no extra cost. So, the missing piece here is just a reasonable way for someone else to duplicate the setup.
Again, there is the assumption that there is a reasonable way for duplicating this setup. RHEL and CentOS have a very clear focus on what they want to achieve.
Yes, basically you have built a repository for your special needs. And in my understanding this was - and is - the way the game was meant to be played by Red Hat.
Red Hat just doesn't go there at all. If they don't distribute it, it is your problem.
That is not entirely true, but is very close to it. Again, RHEL is a product focusing on their customers. If they would have a growing demand for desktop applications, I guess they would do something about it.
Ain't that all the point about an enterprise distribution: that you have the support, the certifications, all the big-dollar-bling-bling?
No, that's really only relevant after something goes wrong. The point of it is the effort that goes into avoiding/fixing the things that go wrong. And the more people that run exactly the same code and report their bugs, sometimes with fixes, the better that turns out.
Not in my world. CentOS is accepted as a full blown RHEL-alternative by nearly everyone doing audits. You will be able to achieve SOX-compliance with almost any auditor I have met so far by using CentOS. Enterprise nowadays is far more than just having a hotline to call when things go wrong. And - at least in my opinion - CentOS is the only community driven Linux today fulfilling enterprise requirements without big time hassle.
If you're messing around with all the upstream-provided stuff, elrepo-kernels and so on, you're already breaking the main (and most expensive) part of the enterprise thingy. And wasn't CentOS all about getting the enterprise-grade distribution cloned has close as possible?
Adding additional applications doesn't hurt the base. It is just better testing for it.
It depends on the application. You will have the effort of backporting patches if you are not able to bring current versions of several libraries to the game. Or you will have to update core libraries.
I can still install CentOS 5.x on older hardware and it will work like a charm, with support and bugfixes. It will not be EOL in 1-2 years, EOL policy covers full life-span of average PC hardware. After 10 years even poor people in Africa or India will get another PC, used one, that can run on CentOS 6.x until end of it's EOL, and on, and on, and on.
Forgive me but the life-span of RHEL or CentOS is not based on the lifetime of average PC hardware. I do have several machines and installations of RHEL 4 and we will have full support of hardware and software till Feb, 28th 2015. Probably longer. That's the E in RHEL and the ent in CentOS. Maybe I got that wrong and we now get back on the Entertainment the E and the ent was meant to mean from the beginning.
I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But that's all kind of irrelevant to what we should be preparing for after a new install of CentOS 7 and what to expect from it.
No, RHEL 4 has Extended Life Phase till 2015. And will probably be even longer supported - at least that's what we're all hoping for. And that is not irrelevant, because - basically - that's what enterprise is about. Getting long term support and that's maybe 10+ years.
Actually - maybe this will amuse someone on the list - we migrated quite a lot of machines in 2011 from CentOS 4 to RHEL 4 - just for getting the ELP-support and the guarantee that we will receive further critical security updates. And we were not alone out there... I know quite a lot of people that would offer the maintainers of CentOS nameless joy if they'd go for the ELP...
On Wed, Feb 26, 2014 at 5:05 PM, Alexander Arlt centos@track5.de wrote:
Much of the point of free software is the fact that once something has been done once, any number of copies of it 'just work' for no extra cost. So, the missing piece here is just a reasonable way for someone else to duplicate the setup.
Again, there is the assumption that there is a reasonable way for duplicating this setup.
There is a way. If you were to hand yum the right package revisions in the right order with the right repos enabled for each, it would build a matching system for you. The low level bits are there.
RHEL and CentOS have a very clear focus on what they want to achieve.
Which currently doesn't involve helping users avoid shooting themselves in the foot.
No, that's really only relevant after something goes wrong. The point of it is the effort that goes into avoiding/fixing the things that go wrong. And the more people that run exactly the same code and report their bugs, sometimes with fixes, the better that turns out.
Not in my world. CentOS is accepted as a full blown RHEL-alternative by nearly everyone doing audits. You will be able to achieve SOX-compliance with almost any auditor I have met so far by using CentOS. Enterprise nowadays is far more than just having a hotline to call when things go wrong. And - at least in my opinion - CentOS is the only community driven Linux today fulfilling enterprise requirements without big time hassle.
Are there restrictions on content from EPEL? Oracle Java? Your own applications? Where do 3rd party additions become a problem in this context?
Adding additional applications doesn't hurt the base. It is just better testing for it.
It depends on the application. You will have the effort of backporting patches if you are not able to bring current versions of several libraries to the game. Or you will have to update core libraries.
Or use static linkage - or alternate locations like software collections. There are ways that don't break the base...
I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But that's all kind of irrelevant to what we should be preparing for after a new install of CentOS 7 and what to expect from it.
No, RHEL 4 has Extended Life Phase till 2015. And will probably be even longer supported - at least that's what we're all hoping for. And that is not irrelevant, because - basically - that's what enterprise is about. Getting long term support and that's maybe 10+ years.
Interesting - I just got the 2012 EOL date from a Red Hat google hit. But I had some early problems with Centos4 and moved to 5 as soon as it came out. I think they mostly involved perl module packaging, though, and might not have affected other uses.
On 02/27/2014 12:25 AM, Les Mikesell wrote:
On Wed, Feb 26, 2014 at 5:05 PM, Alexander Arlt centos@track5.de wrote:
RHEL and CentOS have a very clear focus on what they want to achieve.
Which currently doesn't involve helping users avoid shooting themselves in the foot.
Yes, that's true. At least Red Hat will only help you if you're willing to throw money at 'em.
Not in my world. CentOS is accepted as a full blown RHEL-alternative by nearly everyone doing audits. You will be able to achieve SOX-compliance with almost any auditor I have met so far by using CentOS. Enterprise nowadays is far more than just having a hotline to call when things go wrong. And - at least in my opinion - CentOS is the only community driven Linux today fulfilling enterprise requirements without big time hassle.
Are there restrictions on content from EPEL? Oracle Java? Your own applications? Where do 3rd party additions become a problem in this context?
3rd party additions simply are a problem in this context because it will change CentOS into something not totally Red Hatish. CentOS is not the well suited tool for the enterprise purpose it is because it's CentOS - it is because it's an exact replica of Red Hat.
Of course there are restrictions on content from EPEL, also on the usage of Oracle Java and of course especially there are restrictions regarding "my" own applications. That's all what it's about using an enterprise OS: The baseline is already certified and proven to fulfill requirements so I only have to hassle with my own apps. And using CentOS is not - at least not in my case - about saving money by avoiding buying licenses. Hell, we throw so much money at Red Hat, it wouldn't matter.
CentOS has a clean repository structure, the packages are well sorted out and - most important - I can mirror the repositories and get them easily to any point in the network. This is... harder with RHEL.
We're using CentOS because of the quality, not because of the license fees.
Adding additional applications doesn't hurt the base. It is just better testing for it.
It depends on the application. You will have the effort of backporting patches if you are not able to bring current versions of several libraries to the game. Or you will have to update core libraries.
Or use static linkage - or alternate locations like software collections. There are ways that don't break the base...
Static linkage is basically breaking everything about security. I don't know, how many CVEs regarding the glibc have been in 2013 with a severity of medium+? Too many to manage statically linked software. If you're using statically linked software your basically fooling the concept. Hello, SAP, someone listening?
Installing software in non-standard-locations is mostly the same like doing some static linking.
I assume the 4 is a typo there. RHEL 4's EOL was 2-29-2012, But that's all kind of irrelevant to what we should be preparing for after a new install of CentOS 7 and what to expect from it.
No, RHEL 4 has Extended Life Phase till 2015. And will probably be even longer supported - at least that's what we're all hoping for. And that is not irrelevant, because - basically - that's what enterprise is about. Getting long term support and that's maybe 10+ years.
Interesting - I just got the 2012 EOL date from a Red Hat google hit. But I had some early problems with Centos4 and moved to 5 as soon as it came out. I think they mostly involved perl module packaging, though, and might not have affected other uses.
https://access.redhat.com/site/support/policy/updates/errata/
I'm not sure if this is still the current state of affairs, since we do have our own agreements and settlements with Red Hat, but I think it breaks down to the above.
On 02/27/2014 09:41 AM, Alexander Arlt wrote:
3rd party additions simply are a problem in this context because it will change CentOS into something not totally Red Hatish. CentOS is not the well suited tool for the enterprise purpose it is because it's CentOS - it is because it's an exact replica of Red Hat.
We are talking about ADDITIONAL variant, not changing current release of CentOS. Many people that come to Linux are lured in by stability of Linux. And when they are burned by problems with Fedora or Ubuntu, they start to search of rock solid distro, regardless of little older apps. Because majority of Windows users never update their app anyway. And they are happy using older versions as long as they work as they should. CentOS has best opportunity to be embodiment of Linux people ask for, it has very solid foundations that do not brake (easily). So if upper levels are replaced by app dependency (not really a case except for codecs), that is fair trade-off, especially if chosen version is bug free, and/or maintainers provide little bug-fixes for that release, and they do not rush into providing newer version with newer bugs.
On 02/27/2014 12:05 AM, Alexander Arlt wrote:
So, you turned the cow into a bird. And you did this just because you
want to have a single distribution. That's fine. It kinda feels weird, but if it's the way you want it, it's fine. But don't you think it would have been easier - and probably less nerve-wracking - to just use a more birdish-type of material?
Much of the point of free software is the fact that once something has been done once, any number of copies of it 'just work' for no extra cost. So, the missing piece here is just a reasonable way for someone else to duplicate the setup.
Again, there is the assumption that there is a reasonable way for duplicating this setup. RHEL and CentOS have a very clear focus on what they want to achieve.
Actually, I created everything for 6.x when 6.0 came out. And all I do now is to add new versions of packages from some repositories and manual downloads, or to add some new repository is I come across it. Only thing I never bothers to do is to release release rpm's with all of that packaged, mostly because I disabled GPG signatures so I do not want to raise suspicions that I messed with packages.
But just now I was reading on "cost" option for yum repositories (totally unusable) and I saw that I can assign several GPG keys to single repository, so I might pick up on my "DentOS" project :)
On 02/26/2014 11:02 PM, Alexander Arlt wrote:
Forgive me but the life-span of RHEL or CentOS is not based on the lifetime of average PC hardware. I do have several machines and installations of RHEL 4 and we will have full support of hardware and software till Feb, 28th 2015. Probably longer. That's the E in RHEL and the ent in CentOS. Maybe I got that wrong and we now get back on the Entertainment the E and the ent was meant to mean from the beginning.
I have not said it is BASED ON, I said IT COVERS AVERAGE PC hardware, as in Personal Computer, not Server. Many in the "rest of the world", i.e. non-Western or non-Developed countries use older PC's. Even here at the doorstep of Europe I know people that upgraded their PIII/256MB to P4/2GHz/1GB only because of Youtube CPU requirements. And with WinXP gone soon, many will start thinking about Linux to replace them.
In last 45 days, official CentOS Facebook page had ~1,500 new members. Out of those I am guessing 85-95% were from Asia, and 99.9999% are newbies asking how to do simple things. From 7,500 members in the group, maybe 10 in total have any admin skills worth mentioning. Yeah, the rest should read the Docs, and yes, they are hardly ever going to read anything beside necessity. But if they perceive CentOS as not worth while, hard to start with, they will just leave to other distro's. and will drag dozen other potential users with them. I see that as an failure.
On 02/26/2014 05:02 PM, Alexander Arlt wrote:
Actually I followed the discussion you mentioned but I don't really think that a lot of CentOS-/RHEL-User really care about the Desktop-Ramblings. Still, of course, those are just my assumptions. ...
And, in my opinion, that is an incorrect assumption. I have about an even mix of EL desktops and servers, and this machine I'm using right now is a CentOS 6.5 laptop, and I'm very happy with it, just adding a few third-party repos (ELrepo, EPEL, and nux-dextop are the top three for the desktop experience). I for one care a lot about the CentOS desktop experience.
I'm not really getting the point of the Stability-thing if you have to do so much to turn the cow into a bird. Especially when reading the paragraphs above. If stability means your desktop being stable and not crashing - remove skype (there are a lot of other reasons for doing this besides stability) and be happy. Yet it still will not be 'stable' in the sense of enterprise-usage.
Stability in this context means keeping essentially the same version of core libraries and the kernel across the release lifetime. It means when you do a yum update and the kernel gets updated you don't have to go rebuild (or wait for the third-party repo) to rebuild on a completely different (ABI-speaking) kernel version than before, or rebuild due to some library getting an uprev, etc. Stability means as the system is updated through the entire support lifecycle a program built on the initial release should run, without rebuilding, patching, or otherwise modifying, on the final release ten years later. There are a few exceptions to that (anything built against xulrunner, for one example), but for the most part a single compile run and the program will run from now on on that major version as long as it's supported.
It also means, for the enterprise desktop at least, that the UI isn't changing, sometimes drastically, every six months, and so help desk scripts don't become obsolete before they're out of QA. I support a couple of end users as clients who are running C6 as their _home_ desktop right now, and the low rate of change was one of the strong selling points.
That is of course a two-edged sword, as I have to tell them that if they want something really bleeding edge, like pitivi, they're going to have to accept some other major changes. So far they've chosen to stay stable rather than get the latest and greatest (other than Firefox and Thunderbird, but the ESR line is pretty good about changing slowly).
We also have a scientific instrument here (the Dedicated Interferometer for Rapid Variability (DIRV), which uses our two 26 meter diameter radio telescopes together as an interferometer) where the analysis workstations are RHEL5, and they're not being used as servers. I would hazard to guess that many if not most of the Scientific Linux installs are done for use as workstations and not servers, but I reserve the right to be wrong.
Further, not all things that ELrepo puts out is for desktop reasons. Same with EPEL. Nux-dextop..... well, the name tells you the focus, and I thank Nux for that repo.
On 02/26/2014 12:50 PM, Ljubomir Ljubojevic wrote:
Jim, you have challenged me, but to tie my hands behind my back and grab a rope, because without ability to install "illegal" 3rd party repository (vlc, gstreamer-bad, ...) without any hassle, there is no point in wasting any time on Desktop SIG.
I'm not the one tying your hands. That's the current state of US law, and I'm not any happier about it than you are. That said, there are still a number of things that can be done for a desktop spin beyond debating the legality of certain software.
1. Themes beyond the default for various desktops. I'm reasonably confident that XFCE will see a bit of a boost in usage with el7, since gnome3 seems problematic for some people. The default xfce themes are terrible however, and making a decent theme would go quite a long way toward improving things.
2. Providing newer versions of common desktop environments or software in a sig. for example, a newer XFCE, Mate, Firefox, thunderbird (since that's missing in the el7 beta).
3. Documentation around the proper method of getting the desired result for a useful desktop.
On 02/26/2014 02:51 PM, Jim Perrin wrote:
... 2. Providing newer versions of common desktop environments or software in a sig. for example, a newer XFCE, Mate, Firefox, thunderbird (since that's missing in the el7 beta).
+1 on Thunderbird. See my headers for why.
- Documentation around the proper method of getting the desired result
for a useful desktop.
+10. Suggestion #1: point'em to Nux. :-) http://li.nux.ro/repos.html
Nux-dextop coexists well with EPEL.
For people in the US who want 'legal' codecs that work with gstreamer, see fluendo.com.
Nux has useful packages other than license-encumbered multimedia things (Recent abiword, for instance, and 2.x ardour, for another).
On 02/26/2014 04:47 PM, Les Mikesell wrote:
It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that.
not sure how you say the technical side is fine, for me - its the biggest sticking point about relying on external code. If content in centos.org relies on external repo's - we need to have established a mechanism that allows sync of content before its released. and if we dont rely on that external code, why have it accessible ?
On Thu, Feb 27, 2014 at 10:01 AM, Karanbir Singh mail-lists@karan.org wrote:
On 02/26/2014 04:47 PM, Les Mikesell wrote:
It is the inclusion policy that is the problem with EPEL - the technical side is fine. And I see less chance than ever of changing that.
not sure how you say the technical side is fine, for me - its the biggest sticking point about relying on external code.
In my experience of using it - for about as long is CentOS and EPEL have been around, I can't say that I've ever seen a problem that I could blame on a badly-managed EPEL rpm or repo, other than the fact that they don't consider centos-extras to be 'upstream' - or for that matter any other 3rd party repo, so there is a potential for duplication.
If content in centos.org relies on external repo's - we need to have established a mechanism that allows sync of content before its released. and if we dont rely on that external code, why have it accessible ?
I don't understand this part. "You" may not need EPEL content for the base, but many/most CentOS users will and most SIGs with additional content will need either EPEL or duplicated packages from there. A full mirror would be fine, maybe even better if you can do better vetting before things go from epel-testing to your general release, but it seems silly to duplicate it unless you seriously think you can do a better job with that volume and not slow down new additions. I think cooperation would make more sense. And I'd still like to know if it is possible to automate testing of multiple remote repos to detect potential conflicts and package/file duplication.
On 02/26/2014 12:25 PM, Manuel Wolfshant wrote:
Which is why the list was restricted to these 2 repos only and did not include IUS for instance - even if IUS is one of the most polite 3rd party repos
but then why be unfair to IUS ? or to anyone else for that matter.
the aim of quantification is also based around some level of expectations, and then writing code or putting in place a process that helps both sides of the fence adhere to that expectation. eg. not overwrite rpms from base, might be one ( but then, why not ? if someone wants to ship a new kernel, then that should be ok right ? ).
a slightly more involved case might be the multilib policy, and expecting the repo to adhere to whatever is needed in that scope.
a fairly complex issue would be to have a clearly defined, deliverable security patch policy along with the abililty to force-orphan code that has 'issues'. Scope of what that issues set might contain is another conversation in itself.
thats the sort of quantification were going to need. hope that clears the ambiguity up a bit.
On 26 February 2014 04:53, Johnny Hughes johnny@centos.org wrote:
On 02/26/2014 05:31 AM, Karanbir Singh wrote:
On 02/26/2014 11:25 AM, Manuel Wolfshant wrote:
there are more than 100 repos out there, which ones are we going to add
Those who provide the most desired packages and have been qualified by the community as being in good shape.
this is the important thing - what I've been trying to stress for a while as well. This 'qualified by the community' needs to be a measurable metric.
Lets just get specific here an explain why this can be sticky.
OK, so repoforge and EPEL do not play nicely together. We would, in my opinion, only be able to include one or the other release file in our extras repo as installing both produces broken yum installs of packages.
That is but one example.
I personally would have no real problem with both an epel-release and an elrepo-release RPM in CentOS Extras ... but then why not also nux-desktop or remi or repoforge? Those will not all work together, who do we leave out?
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay fine, that is their choice, they are independent. If you want them in CentOS, tell them on their lists to join as a CentOS SIG.
Just to be clear here.. EPEL doesn't have an organization which could say yay or nay on it. It is a anarcho-syndicalist commune at best (an autonomous commune would be going to far). Some people say yay, some people say nay, some people say whats in it for me. I expect that most are waiting to see how the CentOS SIGs get put into place and release stuff with 7 to see what they want to do.
On Wed, Feb 26, 2014 at 05:53:43AM -0600, Johnny Hughes wrote:
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay
Can you point me to this discussion? I didn't see anything at all on the EPEL devel mailing list, but maybe I missed it.
I don't think that EPEL wants to move out of Fedora (there are a lot of advantages to sharing dist-git and koji, at least), but I at least would be interested in seeing more collaboration where it makes sense. I don't know if a SIG is exactly the right framework for that, but it's possible that it is.
In any case, to my knowledge, this is simply a conversation that hasn't happened yet.
On 02/26/2014 08:15 PM, Matthew Miller wrote:
On Wed, Feb 26, 2014 at 05:53:43AM -0600, Johnny Hughes wrote:
Both EPEL and ELRepo have said they do not want to be a CentOS SIG and want to be "independent". We have offered and they have refused .. Okay
Can you point me to this discussion? I didn't see anything at all on the EPEL devel mailing list, but maybe I missed it.
I don't think that EPEL wants to move out of Fedora (there are a lot of advantages to sharing dist-git and koji, at least), but I at least would be interested in seeing more collaboration where it makes sense. I don't know if a SIG is exactly the right framework for that, but it's possible that it is.
In any case, to my knowledge, this is simply a conversation that hasn't happened yet.
in the coming days/weeks it gets easier to have that conversation as we get repo policies and actually work through content. What we might need to do is establish a baseline that everyone can look at and given the amount of traction EPEL has, see how and what we need to do in order to align things up.
but yea, a conversation that really needs to take place at some point in the future.
On 02/26/2014 05:55 AM, Karanbir Singh wrote:
you are missing the point - what are we making easier ? there are more than 100 repos out there, which ones are we going to add and why and then at that point what do the others need to do in order to also get included ?
I think the simple answer could be if there are enough people for a SIG to integrate a set of repos for the community it gets in. If enough people to run the SIG can't be found, it does not get in.
Carl.
On 02/26/2014 04:10 PM, Carl Trieloff wrote:
On 02/26/2014 05:55 AM, Karanbir Singh wrote:
you are missing the point - what are we making easier ? there are more than 100 repos out there, which ones are we going to add and why and then at that point what do the others need to do in order to also get included ?
I think the simple answer could be if there are enough people for a SIG to integrate a set of repos for the community it gets in. If enough people to run the SIG can't be found, it does not get in.
at a sig level that works, but i believe the question here is about shipping yum configs for repos that are otherwise run off centos.org ( ie. third party content, and mostly packaging fourth party code )
- KB
at a sig level that works, but i believe the question here is about shipping yum configs for repos that are otherwise run off centos.org ( ie. third party content, and mostly packaging fourth party code )
I think what people are looking for is way to have a ppa like experience and if you want more Centos instance in the cloud it is the way to go. I would ship a tool to enable repo on the fly and provide users with the needed infrastructure (copr [1] is developed with this in mind and already have some e7 goodies [2] )
The enterprise guys will anyway manage their own repositories (shipping internal tools, java, etc...) and don't have this kind of repository management issue. For example all our repo are enable through Puppet not rpms.
[1] https://copr.fedoraproject.org/ [2] https://copr.fedoraproject.org/coprs/fulltext/?fulltext=el7
my 2 cents,
On 02/27/2014 02:32 AM, Thomas wrote:
at a sig level that works, but i believe the question here is about shipping yum configs for repos that are otherwise run off centos.org ( ie. third party content, and mostly packaging fourth party code )
I think what people are looking for is way to have a ppa like experience and if you want more Centos instance in the cloud it is the way to go. I would ship a tool to enable repo on the fly and provide users with the needed infrastructure (copr [1] is developed with this in mind and already have some e7 goodies [2] )
The enterprise guys will anyway manage their own repositories (shipping internal tools, java, etc...) and don't have this kind of repository management issue. For example all our repo are enable through Puppet not rpms.
[1] https://copr.fedoraproject.org/ [2] https://copr.fedoraproject.org/coprs/fulltext/?fulltext=el7
my 2 cents,
That's reasonably close to some of the discussions we've already had. Copr was talked about quite heavily early on, and does indeed fit some of what we were looking for. I think it's about 60-70% of what we were after, but needs some more development to be a bit friendlier toward users.
On 02/25/2014 03:32 PM, Akemi Yagi wrote:
What Les meant was the inclusion of the xxx-release packages in the distribution. Those package would not be installed by default, but will be just one yum command away:
yum install elrepo-release
or
yum install epel-release
Scientific Linux has them and that makes it easy for users to install those repos if/when they want them.
In the past, we had specifically avoided doing this for a few reasons:
1. We didn't want to be accused of playing favorites with 3rd party repos
2. We didn't want the expectation of support ("I didn't add anything to the default centos, I just yum-installed it!")
3. We didn't want to ship code that wasn't built/signed by us.
Given the new structure, it may be worth having this conversation again. Thoughts from the community?
With the expansion of scope, SIGs via variants can now do all this, newer kernels etc.
welcome to the new world.
On 02/25/2014 07:49 PM, zf@ancientrocklab.com wrote:
I also Using debian. They have official backports packages team. Which ship new kernel, latest software upgrade for debian stable released.
CentOS lacks of latest kernel, latest software upgrade.
EPEL and elrepo enhanced CentOS. But there be bad side. They were not ship by CentOS community officially. Which means their project may discontinued in any time.
Why Debian do their best provided us the backports packages? Enhanced the debian environment.The sad side is CentOS community Lack of vision.
No responsibility, no future
zf@ancientrocklab.com
*From:* Jim Perrin <mailto:jperrin@centos.org> *Date:* 2014-02-26 08:13 *To:* The CentOS developers mailing list. <mailto:centos-devel@centos.org> *Subject:* Re: [CentOS-devel] Is it possible to merge elrepo.org contribute to centos main repository? On 02/25/2014 03:32 PM, Akemi Yagi wrote: > What Les meant was the inclusion of the xxx-release packages in the > distribution. Those package would not be installed by default, but > will be just one yum command away: > > yum install elrepo-release > > or > > yum install epel-release > > Scientific Linux has them and that makes it easy for users to install > those repos if/when they want them. In the past, we had specifically avoided doing this for a few reasons: 1. We didn't want to be accused of playing favorites with 3rd party repos 2. We didn't want the expectation of support ("I didn't add anything to the default centos, I just yum-installed it!") 3. We didn't want to ship code that wasn't built/signed by us. Given the new structure, it may be worth having this conversation again. Thoughts from the community? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Akemi Yagi -
Alexander Arlt -
Carl Trieloff -
Jim Perrin -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Matthew Miller -
Stephen John Smoogen -
Thomas -
Trevor Hemsley -
zf＠ancientrocklab.com