Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
Thanks, Marty
On 04/18/2014 07:26 AM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
My suggestion for this, if you're already messing with kickstarts anyway, is to simply add the EPEL repository URL to your kickstart file, and add epel-release to the %packages. Lines like this would do it:
repo --name=epel --baseurl=http://mirror.steadfast.net/epel/6/x86_64/
%packages epel-release
EPEL still retains a policy of shipping only non-replacement packages. As long as you're comfortable with the package quality in EPEL and not shipping any other external repos enabled by default, there's not a lot of risk to shipping a fresh install with epel-release installed.
On 4/18/2014 11:45 AM, Kevin Stange wrote:
On 04/18/2014 07:26 AM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
My suggestion for this, if you're already messing with kickstarts anyway, is to simply add the EPEL repository URL to your kickstart file, and add epel-release to the %packages. Lines like this would do it:
repo --name=epel --baseurl=http://mirror.steadfast.net/epel/6/x86_64/
Yes, thank you.
I learned the wisdom of kickstarts much later - I found Scientific a bit easier to use at first because it does offer several such -release packages in their main repo. My point, I believe, is that including epel-release in the main CentOS repo will make for a better experience for those who wish to use EPEL, and offers very little in the way of risk for those who don't. I believe it will be a better user experience for those coming from Debian-based distributions, who might be wondering where small but very useful utilities like htop and sshpass are, as well as many useful scripting language modules and all the other goodies there. I realize the current bar for getting EPEL installed on CentOS isn't exactly high, but I also don't think it's especially obvious for people who are new to it, either.
I understand there's going to be a desire to not diverge from Upstream, which this would mean, but I also think the benefits of including the package outweigh the disadvantages.
Thanks, Marty
On 04/18/2014 01:26 PM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
CentOS-Extras is enabled by default, why dont we look at dropping epel-release into there ?
On 04/24/2014 11:55 AM, Karanbir Singh wrote:
On 04/18/2014 01:26 PM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
CentOS-Extras is enabled by default, why dont we look at dropping epel-release into there ?
I'm fine with that.
On 24/04/14 17:55, Karanbir Singh wrote:
On 04/18/2014 01:26 PM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
CentOS-Extras is enabled by default, why dont we look at dropping epel-release into there ?
That sounds like a brilliant idea.
T
On Thu, Apr 24, 2014 at 12:40 PM, Trevor Hemsley trevor.hemsley@ntlworld.com wrote:
On 24/04/14 17:55, Karanbir Singh wrote:
On 04/18/2014 01:26 PM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
CentOS-Extras is enabled by default, why dont we look at dropping epel-release into there ?
That sounds like a brilliant idea.
Brilliant, but hardly new. I guess the world has changed since the lengthy thread around: http://lists.centos.org/pipermail/centos-devel/2012-September/008830.html
Funny things happen when different organizations suddenly have the same owner.
On 04/24/2014 07:03 PM, Les Mikesell wrote:
Brilliant, but hardly new. I guess the world has changed since the lengthy thread around: http://lists.centos.org/pipermail/centos-devel/2012-September/008830.html
Funny things happen when different organizations suddenly have the same owner.
I recommend you actually read the thread Les, it might surprise you.
- KB
On Thu, Apr 24, 2014 at 3:14 PM, Karanbir Singh mail-lists@karan.org wrote:
On 04/24/2014 07:03 PM, Les Mikesell wrote:
Brilliant, but hardly new. I guess the world has changed since the lengthy thread around: http://lists.centos.org/pipermail/centos-devel/2012-September/008830.html
Funny things happen when different organizations suddenly have the same owner.
I recommend you actually read the thread Les, it might surprise you.
How can I be surprised? I wrote some of it - and nothing has changed yet. And I'll stand by my preference that 3rd party repos be included but disabled by default. If you have more than one enabled during updates you are likely to hit conflicts or just slightly incompatible versions of the same package name and leapfrogging versions. EPEL may be a necessary evil, but it doesn't include everything so you'll probably have to make it co-exist with other 3rd party repos. Disabling by default keeps it from causing trouble.
But, it is very, very handy to be able to do 'yum --enablerpo=xxx search pattern' without a lot of prior contortions. And likewise for the install when you find the package you want.
On 04/24/2014 09:47 PM, Les Mikesell wrote:
I recommend you actually read the thread Les, it might surprise you.
How can I be surprised? I wrote some of it - and nothing has changed yet. And I'll stand by my preference that 3rd party repos be included but disabled by default. If you have more than one enabled
removing random babble... the thread you refer to is pretty clear about not shipping in distro, i dont see that as having changed here either.
rest of it is just hand waving
On Thu, Apr 24, 2014 at 3:50 PM, Karanbir Singh mail-lists@karan.org wrote:
rest of it is just hand waving
If you enjoy surprises.
On Thu, Apr 24, 2014 at 03:53:32PM -0500, Les Mikesell wrote:
If you enjoy surprises.
Must. Have. Last. Word.
John
On Thu, Apr 24, 2014 at 4:03 PM, John R. Dennison jrd@gerdesas.com wrote:
On Thu, Apr 24, 2014 at 03:53:32PM -0500, Les Mikesell wrote:
If you enjoy surprises.
Must. Have. Last. Word.
Really? From the person who brought up ponies last time around?
On 04/24/2014 03:53 PM, Les Mikesell wrote:
On Thu, Apr 24, 2014 at 3:50 PM, Karanbir Singh mail-lists@karan.org wrote:
rest of it is just hand waving
If you enjoy surprises.
Well ... my opinion is this:
Just because the release RPM is in extras does not mean that people have to (or will) install it. People have to "yum install epel-release" before they get access to the repo.
I would assume if someone wanted to install the epel-release package, the majority of them would want at least the main binary repository to be enabled by default.
If someone wants EPEL installed and wants it instead off (I think by far the minority ... does someone disagree?), they can modify their .repo file manually to turn it off.
That being the case, I would think the best thing is that we just build, sign, and push the current release file from the EPEL repo for c5 and c6 in our CentOS Extras .. in the appropriate spot.
Thoughts?
Thanks, Johnny Hughes
On 04/25/2014 03:41 PM, Johnny Hughes wrote:
On 04/24/2014 03:53 PM, Les Mikesell wrote:
On Thu, Apr 24, 2014 at 3:50 PM, Karanbir Singh mail-lists@karan.org wrote:
rest of it is just hand waving
If you enjoy surprises.
Well ... my opinion is this:
Just because the release RPM is in extras does not mean that people have to (or will) install it. People have to "yum install epel-release" before they get access to the repo.
I would assume if someone wanted to install the epel-release package, the majority of them would want at least the main binary repository to be enabled by default.
If someone wants EPEL installed and wants it instead off (I think by far the minority ... does someone disagree?), they can modify their .repo file manually to turn it off.
That being the case, I would think the best thing is that we just build, sign, and push the current release file from the EPEL repo for c5 and c6 in our CentOS Extras .. in the appropriate spot.
Thoughts?
I have to play devil's advocate here. Quote from http://lists.centos.org/pipermail/centos-devel/2014-February/009830.html:
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 ?
On 25.04.2014 13:49, Manuel Wolfshant wrote:
Thoughts?
I have to play devil's advocate here. Quote from http://lists.centos.org/pipermail/centos-devel/2014-February/009830.html:
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 ?
Guys, we are beating around the bush here and missing the obvious - which is even more obvious since the RH acquisition.
We all know EPEL is "special"; first of all there are loads of developers contributing to it, second it is officially part of the RedHat world (legalese bullshit aside), third it probably has the least number of complaints against it, implying good quality.
Given the above I'd say it's pretty safe and useful to add epel-release to Extras.
Why don't we add another of the 100s of repos? Because none of the other tick all the boxes above.
My 2 slips of gold-pressed latinum.
Lucian
On 04/25/2014 08:17 AM, Nux! wrote:
On 25.04.2014 13:49, Manuel Wolfshant wrote:
Thoughts?
I have to play devil's advocate here. Quote from http://lists.centos.org/pipermail/centos-devel/2014-February/009830.html:
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 ?
Guys, we are beating around the bush here and missing the obvious - which is even more obvious since the RH acquisition.
We all know EPEL is "special"; first of all there are loads of developers contributing to it, second it is officially part of the RedHat world (legalese bullshit aside), third it probably has the least number of complaints against it, implying good quality.
Given the above I'd say it's pretty safe and useful to add epel-release to Extras.
Why don't we add another of the 100s of repos? Because none of the other tick all the boxes above.
My 2 slips of gold-pressed latinum.
Agreed ...
On Fri, Apr 25, 2014 at 7:41 AM, Johnny Hughes johnny@centos.org wrote:
Well ... my opinion is this:
Just because the release RPM is in extras does not mean that people have to (or will) install it. People have to "yum install epel-release" before they get access to the repo.
Yes, I agree that having to type yum install epel-release instead of, say yum install http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm is a slight improvement, but not exactly world-changing. If you know to do one of those things you would probably figure out the other. But, it doesn't solve the bigger issue.
I would assume if someone wanted to install the epel-release package, the majority of them would want at least the main binary repository to be enabled by default.
That's probably what people think they want anyway. But it can be complicated, particularly when EPEL adds content that you were previously getting from a different repo. My old poster child example for this was viewvc which was in rpmforge long before epel, and when epel added it, they used a higher version number and an incompatible configuration. So, no warnings, no conflicts, just a silently broken package after an update. You can blame that one one on using rpmforge, but for something that hits a little closer to home, do you know where your NX libs came from and when it changed? Someone on the freenx list claims that the switch to EPEL's version broke his normal X operation by changing LD_LIBRARY_PATH to find the wrong libX11.so. (Not sure why he had an old copy under /usr/lib64/nx/X11/, but it points out the potential for surprises from an always-enabled EPEL). Even though they claim to have a policy of not conflicting with or replacing upstream packages, only RH base is 'upstream'.
If someone wants EPEL installed and wants it instead off (I think by far the minority ... does someone disagree?), they can modify their .repo file manually to turn it off.
I was just hoping someone would come up with a solution for the bigger problem of uncoordinated repos. Like making yum need an extra option to make it take an update from a different repo than the original install. Or some external database that tracks conflicts and duplicates across repos with different contents/policies. Or a way to force packages from certain repos into a software-collections type space even if they weren't built that way.
That being the case, I would think the best thing is that we just build, sign, and push the current release file from the EPEL repo for c5 and c6 in our CentOS Extras .. in the appropriate spot.
Thoughts?
Doing that would not be a problem - but it doesn't solve the big problem either.
On 25/04/14 13:41, Johnny Hughes wrote:
On 04/24/2014 03:53 PM, Les Mikesell wrote:
On Thu, Apr 24, 2014 at 3:50 PM, Karanbir Singh mail-lists@karan.org wrote:
rest of it is just hand waving
If you enjoy surprises.
Well ... my opinion is this:
Just because the release RPM is in extras does not mean that people have to (or will) install it. People have to "yum install epel-release" before they get access to the repo.
I would assume if someone wanted to install the epel-release package, the majority of them would want at least the main binary repository to be enabled by default.
If someone wants EPEL installed and wants it instead off (I think by far the minority ... does someone disagree?), they can modify their .repo file manually to turn it off.
That being the case, I would think the best thing is that we just build, sign, and push the current release file from the EPEL repo for c5 and c6 in our CentOS Extras .. in the appropriate spot.
Thoughts?
Hi Johnny,
I agree, but for slightly different reasons. IMHO it is not up to you, me or anyone else to determine if a repo should be enabled or disabled by default - it is ONLY up to the repo themselves to decide how they ship their config file. Then, when support queries come in, they can expect a certain default configuration. If the end user chooses to change the default configuration, that is their prerogative.
So yes, by all means ship repo release packages in extras, but ship them 'as is', bugs and all from the upstream repo. Personally, I'd much prefer you didn't even rebuild them - I'd rather see CentOS just redistribute the upstream built and signed binary packages via the extras repository.
Just my 2 cents.
On 04/26/2014 03:54 PM, Ned Slider wrote:
So yes, by all means ship repo release packages in extras, but ship them 'as is', bugs and all from the upstream repo. Personally, I'd much prefer you didn't even rebuild them - I'd rather see CentOS just redistribute the upstream built and signed binary packages via the extras repository.
They at least need to be re-signed. Yum is going to be unhappy about installing packages with unknown signatures from CentOS Extras.
On 04/26/2014 04:59 PM, Kevin Stange wrote:
On 04/26/2014 03:54 PM, Ned Slider wrote:
So yes, by all means ship repo release packages in extras, but ship them 'as is', bugs and all from the upstream repo. Personally, I'd much prefer you didn't even rebuild them - I'd rather see CentOS just redistribute the upstream built and signed binary packages via the extras repository.
They at least need to be re-signed. Yum is going to be unhappy about installing packages with unknown signatures from CentOS Extras.
Well, things installed from CentOS extras need to be signed with our key (as the key from the other repo will not be available until the release RPM is installed).
So we can not leave the RPM signed by the key that it is going to install, because it will not install unless you manually install their key first.
That leaves the question if I will "resign" someone else's RPM with the CentOS key and stick it in extras ... and I think the answer is NO for that ... so, I will have to build, then sign them.
I don't think people want the CentOS Project to blindly sign things that other groups, whoever they are, build.
agreed, I was about to suggest the same thing
On Thu, Apr 24, 2014 at 12:55 PM, Karanbir Singh mail-lists@karan.orgwrote:
On 04/18/2014 01:26 PM, Martin Jackson wrote:
Hello,
With the changes in CentOS, would it be possible now to include the epel-release package in the main CentOS repositories? I believe this would help make the process of setting CentOS up a bit more convenient and accessible for both new users (who may have an awkward time finding and installing the epel release package) as well as more veteran administrators, who could effectively choose to enable epel by default by including it in kickstarts and so on.
CentOS-Extras is enabled by default, why dont we look at dropping epel-release into there ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Jim Perrin -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Kevin Stange -
Lamar Owen -
Les Mikesell -
Manuel Wolfshant -
Martin Jackson -
Mike McLean -
Ned Slider -
Nux! -
Trevor Hemsley