hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
1) Shipping epel-release in CentOS-Extras, so its installable, usable out of the box.
2) Shipping epel-release in the distro itself, with the epel repos's enabled=false. This is the option that most people seem to want, but I am least keen on.
3) do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards,
On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
EPEL is the first thing I add to most servers I manage (CentOS or RHEL). I would like the added convenience of having it included by default -- either of the options you listed would be OK for me from that perspective. However, including it in the base OS doesn't make a lot of sense to me as we look for a way to scale it out to include other repos as well. Adding those to CentOS Extras seems like the way to go to make it a low barrier of entry to enable repos (I assume with some sort of qualification before we include them).
I have to say though, I rarely use CentOS Extras, and I'd be more likely to stick with adding EPEL in a kickstart file. I understand that's not for everyone though.
<snip from kickstart> repo --name=epel --baseurl=http://ftp.osuosl.org/pub/fedora-epel/5/x86_64/ [...] %packages @base epel-release [...] </snip>
-Jeff
On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singhmail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
EPEL is the first thing I add to most servers I manage (CentOS or RHEL). I would like the added convenience of having it included by default -- either of the options you listed would be OK for me from that perspective. However, including it in the base OS doesn't make a lot of sense to me as we look for a way to scale it out to include other repos as well. Adding those to CentOS Extras seems like the way to go to make it a low barrier of entry to enable repos (I assume with some sort of qualification before we include them).
I have to say though, I rarely use CentOS Extras, and I'd be more likely to stick with adding EPEL in a kickstart file. I understand that's not for everyone though.
<snip from kickstart> repo --name=epel --baseurl=http://ftp.osuosl.org/pub/fedora-epel/5/x86_64/ [...] %packages @base epel-release [...] </snip>
That IS easy to do when you one kickstarts. But this applies to people who do many installs and have a certain infrastructure. Those people have no need for the instructions in the Centos wiki or for help in IRC. IRC experience shows that most users who need packages from epel/elrepo/IUS and come by #centos have no fscking idea about how to install / activate . I've seen cases where 30 min were needed to just grasp OUR wiki and Fedora's. The record I've seen was 45 min needed for the Fedora part. For those who do know, the barrier does not exist and ks / puppet / chef etc is the normal way. They probably already have private mirrors, maybe with the needed packages already prepared / downloaded from the upstream channels they need . But for those who do not have prior knowledge, like it or not, yum install epel-release is way easier than to follow "go read our wiki page on adding 3rd party repos and pay attention to priorities". Yes, I know, they should read/learn. But helping them by excluding the "hunt for epel-release and install it" part will not hurt.
On Fri, 14 Sep 2012, Manuel Wolfshant wrote:
On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singhmail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
But for those who do not have prior knowledge, like it or not, yum install epel-release is way easier than to follow "go read our wiki page on adding 3rd party repos and pay attention to priorities". Yes, I know, they should read/learn. But helping them by excluding the "hunt for epel-release and install it" part will not hurt.
And yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7 is hard?
Googling "install epel-release" gets the following url: http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_t...
If they can find IRC they should be able to follow enough directions to google as above.
Oh and in case it is not clear I am in the do nothing camp.
Regards,
On 09/14/2012 12:44 AM, me@tdiehl.org wrote:
On Fri, 14 Sep 2012, Manuel Wolfshant wrote:
On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singhmail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
But for those who do not have prior knowledge, like it or not, yum install epel-release is way easier than to follow "go read our wiki page on adding 3rd party repos and pay attention to priorities". Yes, I know, they should read/learn. But helping them by excluding the "hunt for epel-release and install it" part will not hurt.
And yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7 is hard?
No, it is not. But I've seen more than once people getting confused by the fact that the package name changes over time or by confusion between the release version and the distro version for which it is intended.
Googling "install epel-release" gets the following url: http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_t...
Right. Only that you KNEW what to google for. Incidentally you also took for granted that the package name is "epel-release".
If they can find IRC they should be able to follow enough directions to google as above.
If only that was true...
Oh and in case it is not clear I am in the do nothing camp.
On Fri, Sep 14, 2012 at 12:53:11AM +0300, Manuel Wolfshant wrote:
Right. Only that you KNEW what to google for. Incidentally you also took for granted that the package name is "epel-release".
Google for "epel on centos" or "hwo to use epel with centos" or anything else and you will get the same results.
If only that was true...
And that's centos' problem... how? Again, re-thinking of career paths comes to mind.
I'm not trying to single you out here, Manuel, even though it probably seems like it from the thread, and my apologies if you think I am. I just don't see any merit to this idea whatsoever; it's an idiotic one from the get-go. Either people are able to cope with a real OS or they are not. Catering to those that aren't is just going to increase support burdens on people on the lists and irc channels for little, if any, positive outcome.
Adding a repo is not rocket science. If there are issues then fix the centos wiki. But from my last read of that page it should be pretty straight-forward if people read and follow links where needed.
John
On 09/14/2012 01:36 AM, John R. Dennison wrote:
On Fri, Sep 14, 2012 at 12:53:11AM +0300, Manuel Wolfshant wrote:
Right. Only that you KNEW what to google for. Incidentally you also took for granted that the package name is "epel-release".
Google for "epel on centos" or "hwo to use epel with centos" or anything else and you will get the same results.
Or not. Google results are tailored based on your previous searches. A friend of mine I used to work for was very excited to see his company listed as second in google's results on his specific queries performed from his office workstation. Guess what? It was not even on the second page when his sister performed the same search from her home computer.
If only that was true...
And that's centos' problem... how? Again, re-thinking of career paths comes to mind.
It's not. But helping them does not hurt anyone and increases those users' satisfaction level.
I'm not trying to single you out here, Manuel, even though it probably seems like it from the thread, and my apologies if you think I am.
There is no need for apologies. We are just professionals debating a technical thing and that's all. Not to mention that I also play a bit of the devil's advocate role. I help when I can/want in and out the official support channels. I am not a fan of spoon feeding but I do it from time to time if I find it useful. In this particular case my perception is that lowering the barrier will help users. Even the fact that the issue was raised at LinuxCon proves that there exists a need. And the sad truth is that no matter what WE as professionals want, users do what they want. And most of the time they want to do as little as possible. Quality is a nice thing to have. However people would rather pay for convenience instead.
I just don't see any merit to this idea whatsoever; it's an idiotic one from the get-go. Either people are able to cope with a real OS or they are not.
I know quite a few people who see the computer as a tool and nothing else. They need this specific tool to solve a problem and they are not willing to invest their time into learning more than a minimal needed to have things going. I know that in an ideal world all those should read the fine manuals but if you are a physicist interested in just having a local $whatever server which will help you and your colleagues to share data you will not spend more than the bare minimum of your time into setting it up. And the lower this barrier, the better for those people. You and me are professionals and dedicate most of our time to computers. Those who would benefit from the lower barrier are not. They will not use kickstarts because they do not have the infra for that. They would not use puppet. They would not use spacewalk ( what the hack, I do not use spacewalk ! ). They would just boot from an install disk, click click , Once done they just use putty to connect to it and they want to add whatever they are missing without spending time in bing ( yes, bing might very well be their default search engine and you know very well why ). THOSE are the people who need a lower entry barrier.
Catering to those that aren't is just going to increase support burdens on people on the lists and irc channels for little, if any, positive outcome.
Based on what I've seen on IRC during the last months I think the opposite is true.
Adding a repo is not rocket science. If there are issues then fix the centos wiki. But from my last read of that page it should be pretty straight-forward if people read and follow links where needed.
Try to imagine that you read that after it has been translated by google from a language you do not understand. CentOS is quite used by people who do not grasp English well enough. Sometimes (by choice or not..) even by people who have limited computer knowledge. Lowering the barrier helps them with no impact on those with proper knowledge.
On Thu, Sep 13, 2012 at 5:44 PM, me@tdiehl.org wrote:
On Fri, 14 Sep 2012, Manuel Wolfshant wrote:
On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singhmail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
But for those who do not have prior knowledge, like it or not, yum install epel-release is way easier than to follow "go read our wiki page on adding 3rd party repos and pay attention to priorities". Yes, I know, they should read/learn. But helping them by excluding the "hunt for epel-release and install it" part will not hurt.
And yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7 is hard?
Googling "install epel-release" gets the following url: http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_t...
If they can find IRC they should be able to follow enough directions to google as above.
Oh and in case it is not clear I am in the do nothing camp.
Regards, Tom
We must immediately stop drawing a distinction between "those idiots" and "the knowledgeable people" because it has nothing to do with that. Anyone who thinks that needs to grow up and realize that making life easier has nothing to to with "dumbing things down", but in fact is the very point of advancing technology.
The process of automating installation is always about eliminating one step here or there. I could easily say that following an install document using copy/paste is easy enough and that scripting or automating via puppet/chef is just a waste of time and only coddles to the idiots who can't follow instructions. A few years ago some of you might have agreed, but not today.
The "do nothing" approach has absolutely no advantage. There is no one forcing you to use the packages. The only people it gains are the ones who want to use it, and the only people it hurts is .. nobody. It's up to the CentOS release team if they want to keep the packages up to date. Otherwise, it affects nobody else negatively.
As is typical of a discussion like this, everyone is ignoring the second part of the request, which is discussing the standards that should be used when deciding to include a repo in the repository.
I typically use priorities for all 3rd party repos, but there is no simple way to configure that directly via a package install. It seems that the inclusion of any 3rd party repos would have to solve that problem somehow. Are there any yum modules that provide protection and don't require manual editing of yum repo files?
Another idea is something along the lines of the cr repo, where there is a package in the extras repo that will enable a "3rd-party" repo which actually contains the -release packages. The "3rd-party" package could have some requirements of it's own, such as yum-priorities, etc... Admittedly that's a bit convoluted, and may not make things easier, but it's a way of trying to bring in other packages without modifying the original -release packages.
❧ Brian Mathis
On 13/09/12 16:32, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
This one looks best from POV of amount of work needed and also because it won't be enabled by default.
I'd also suggest adding ELRepo...
Perhaps a big note in the release notes saying it's there but not endorsed etc etc?
Trevor
On 13/09/12 16:54, Trevor Hemsley wrote:
On 13/09/12 16:32, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
For information, Scientific Linux adds various 3rd party repo release files to their distro although AFAIK none are installed by default. See here:
http://www.scientificlinux.org/distributions/6x/features/added
yum repositories Summary : Various Yum Repositories These are not supported by Scientific Linux but are here for your convenience.
This is not installed by default. -- adobe-release -- atrpms-repo -- elrepo-release -- epel-release -- rpmforge-release
I'd also suggest adding ELRepo...
I should declare an interest in that I'm a member of elrepo.
We have worked with SL where needed to ensure the elrepo-release package is kept up to date within their repositories and try to maintain consistent / stable behaviour and a minimal release schedule consistent with an Enterprise Linux distribution.
I personally have no objections / concerns with CentOS including our repo release package should you so want, but I feel it inappropriate for me to offer further opinion on the matter given my vested interest in the subject :-)
On 9/13/2012 1:48 PM, Ned Slider wrote:
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
yum repositories Summary : Various Yum Repositories These are not supported by Scientific Linux but are here for your convenience.
This is not installed by default. -- adobe-release -- atrpms-repo -- elrepo-release -- epel-release -- rpmforge-release
I wound´t mind it this repos came installed but disabled buy default, I dont know, but it seems that everybody ends up installing some of them anyway. But, if they came disabled, the vanilla CentOS environment would not be affected without user intervention. CentOS would remain CentOS the same it is today.
[]s.
On 09/13/2012 06:54 PM, Trevor Hemsley wrote:
On 13/09/12 16:32, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
This one looks best from POV of amount of work needed and also because it won't be enabled by default.
I'd also suggest adding ELRepo...
+1 for both repos to have their *-release included in centos-extras. and we should also evaluate IUS.
Perhaps a big note in the release notes saying it's there but not endorsed etc etc?
Absolutely ! Something along "These packages are here for your convenience only; support for using these repos and for the packages taken from these repos should be asked for in their respective avenues".
On Fri, Sep 14, 2012 at 12:24:15AM +0300, Manuel Wolfshant wrote:
Absolutely ! Something along "These packages are here for your convenience only; support for using these repos and for the packages taken from these repos should be asked for in their respective avenues".
Yeah, because that has worked out oh so well over the years. You ship it, you support it. It's that simple.
The steps to add external repos are well documented on the wiki.
If people can't figure out how to add a 3rd-party repo on their own they need to re-evaluate their role as they are out of their league.
Strong -1 on this idea.
John
On Thu, Sep 13, 2012 at 4:28 PM, John R. Dennison jrd@gerdesas.com wrote:
"These packages are here for your convenience only; support forusing these repos and for the packages taken from these repos should be asked for in their respective avenues".
Yeah, because that has worked out oh so well over the years. You ship it, you support it. It's that simple.
Wait, what???? We get support?
If people can't figure out how to add a 3rd-party repo on their own they need to re-evaluate their role as they are out of their league.
Strong -1 on this idea.
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings. Then a simple yum command line override can search/install from them without killing the hour it's going to take to figure out which repos you need to install and likely leaving them enabled and much, much more likely to cause accidental problems.
On 15/09/12 17:04, Les Mikesell wrote:
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings.
But that's not your decision to make - it's a decision for the repo themselves how they configure their repo in their config file.
The way for a distro to have "control" is not to install the repo-release package by default to start with, just have it present in the repos if that's what people want.
A sensible criteria for including any repo might be that if it replaces packages from the distro then it should be disabled (enabled=0) by default, but it's not a setting for you (the distro) to change.
On Sat, Sep 15, 2012 at 1:01 PM, Ned Slider ned@unixmail.co.uk wrote:
On 15/09/12 17:04, Les Mikesell wrote:
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings.
But that's not your decision to make - it's a decision for the repo themselves how they configure their repo in their config file.
If it is included, it can be patched. Debian/ubuntu do this somewhat sensibly but there you have to make a one-time selection to enable the extra repos. I think it is nicer to keep the alternative ones (except maybe EPEL) disabled.
The way for a distro to have "control" is not to install the repo-release package by default to start with, just have it present in the repos if that's what people want.
That's sort-of reasonable, but the thing you need to be able to do is "yum search" across the repos or "yum info" a package that may be in one or more them. To even do that, you have to install the repo files. And then you'll probably have them enabled and likely to clobber things in an update when you just wanted to look.
A sensible criteria for including any repo might be that if it replaces packages from the distro then it should be disabled (enabled=0) by default, but it's not a setting for you (the distro) to change.
That's not the only criteria. Some packages don't upgrade gracefully or take extra manual actions (opennms, drbl, probably others...). And you may not want to selectively disable them on every yum update run when you want normal updates.
On 16/09/12 17:19, Les Mikesell wrote:
On Sat, Sep 15, 2012 at 1:01 PM, Ned Sliderned@unixmail.co.uk wrote:
On 15/09/12 17:04, Les Mikesell wrote:
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings.
But that's not your decision to make - it's a decision for the repo themselves how they configure their repo in their config file.
If it is included, it can be patched. Debian/ubuntu do this somewhat sensibly but there you have to make a one-time selection to enable the extra repos. I think it is nicer to keep the alternative ones (except maybe EPEL) disabled.
As a repo provider, if you patch it you can support it as it's no longer what I ship. I don't want the extra support load when you break what I ship.
Which is pretty much the same response you'll hear from CentOS every time someone posts with a system running a non-CentOS kernel.
IMHO that's not what CentOS wants here. It's certainly not what 3rd party repo providers would want either.
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user runs 'yum update' and the repo file gets updated from the repo the user will be back at the repo's default settings regardless of how the distro may or may not have initially patched the repo file.
It's simply not your config file to alter so if you don't like the defaults don't ship it. Make that a criteria from the start together with guidance on what defaults are acceptable for inclusion.
On 09/16/2012 09:05 PM, Ned Slider wrote:
On 16/09/12 17:19, Les Mikesell wrote:
On Sat, Sep 15, 2012 at 1:01 PM, Ned Sliderned@unixmail.co.uk wrote:
On 15/09/12 17:04, Les Mikesell wrote:
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings.
But that's not your decision to make - it's a decision for the repo themselves how they configure their repo in their config file.
If it is included, it can be patched. Debian/ubuntu do this somewhat sensibly but there you have to make a one-time selection to enable the extra repos. I think it is nicer to keep the alternative ones (except maybe EPEL) disabled.
As a repo provider, if you patch it you can support it as it's no longer what I ship. I don't want the extra support load when you break what I ship.
Which is pretty much the same response you'll hear from CentOS every time someone posts with a system running a non-CentOS kernel.
IMHO that's not what CentOS wants here. It's certainly not what 3rd party repo providers would want either.
Which is why in my opinion the better option is to - include the release rpm exactly as shipped by the 3rd party repo, - in centos-extras, so that a) it is [ more or less] obvious [ for those who bother to read about the CentOS repositories] that it is supplied for user convenience but not part of CentOS and b) it cannot get installed by default unless the user|admin explicitly asks for it to be installed
Bonus points for updating it in the CentOS mirrors when the 3rd party repo admins decide to update it, but this is not mandatory as the first update after install will update the release.rpm, too , if needed.
For those who are afraid about the conflicts/overrides between EPEL and [base]: those conflicts/overrides normally appear ONLY for packages which are NOT distributed as part of main RHEL but in additional channels which require separate subscriptions. Those who use the special channels are well experienced and I am 100% sure that they would not cry for help in the CentOS support channels. And in the rare cases when conflicts do occur ( mainly when RHEL releases new minor versions and their package maintainers do not bother to sync with EPEL maintainers ), EPEL does its best to take all the needed steps to solve the conflicts. i.e. it usually removes the offending packages. So please, let's not throw away the baby together with the dirty water.
On 16/09/12 19:26, Manuel Wolfshant wrote:
On 09/16/2012 09:05 PM, Ned Slider wrote:
On 16/09/12 17:19, Les Mikesell wrote:
On Sat, Sep 15, 2012 at 1:01 PM, Ned Sliderned@unixmail.co.uk wrote:
On 15/09/12 17:04, Les Mikesell wrote:
I disagree. I'd much rather see commonly needed 3rd party repos included but with enabled=0. settings.
But that's not your decision to make - it's a decision for the repo themselves how they configure their repo in their config file.
If it is included, it can be patched. Debian/ubuntu do this somewhat sensibly but there you have to make a one-time selection to enable the extra repos. I think it is nicer to keep the alternative ones (except maybe EPEL) disabled.
As a repo provider, if you patch it you can support it as it's no longer what I ship. I don't want the extra support load when you break what I ship.
Which is pretty much the same response you'll hear from CentOS every time someone posts with a system running a non-CentOS kernel.
IMHO that's not what CentOS wants here. It's certainly not what 3rd party repo providers would want either.
Which is why in my opinion the better option is to
- include the release rpm exactly as shipped by the 3rd party repo,
agreed!
- in centos-extras, so that a) it is [ more or less] obvious [ for those
who bother to read about the CentOS repositories] that it is supplied for user convenience but not part of CentOS and b) it cannot get installed by default unless the user|admin explicitly asks for it to be installed
spot on!
Bonus points for updating it in the CentOS mirrors when the 3rd party repo admins decide to update it, but this is not mandatory as the first update after install will update the release.rpm, too , if needed.
absolutely!
For those who are afraid about the conflicts/overrides between EPEL and [base]: those conflicts/overrides normally appear ONLY for packages which are NOT distributed as part of main RHEL but in additional channels which require separate subscriptions. Those who use the special channels are well experienced and I am 100% sure that they would not cry for help in the CentOS support channels. And in the rare cases when conflicts do occur ( mainly when RHEL releases new minor versions and their package maintainers do not bother to sync with EPEL maintainers ), EPEL does its best to take all the needed steps to solve the conflicts. i.e. it usually removes the offending packages. So please, let's not throw away the baby together with the dirty water.
On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider ned@unixmail.co.uk wrote:
If it is included, it can be patched. Debian/ubuntu do this somewhat sensibly but there you have to make a one-time selection to enable the extra repos. I think it is nicer to keep the alternative ones (except maybe EPEL) disabled.
As a repo provider, if you patch it you can support it as it's no longer what I ship. I don't want the extra support load when you break what I ship.
If setting a repo file to enabled=0 breaks something, then no one should be using it in the first place. As for support, does that mean you'll come fix my box when a different 3rd part repo adds a package with the same name and the packages clobber each other during updates? If not, how is not having your support any different?
Which is pretty much the same response you'll hear from CentOS every time someone posts with a system running a non-CentOS kernel.
And yet, everyone has policies that keep them from accepting all packages into one repository. Lovely... And worse, where the point of the repo is to supply updated packages, they often aren't renamed and intentionally conflict with others.
IMHO that's not what CentOS wants here. It's certainly not what 3rd party repo providers would want either.
I'm sure it isn't. But it would serve the users that need packages they each refuse to accept.
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user runs 'yum update' and the repo file gets updated from the repo the user will be back at the repo's default settings regardless of how the distro may or may not have initially patched the repo file.
Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
It's simply not your config file to alter so if you don't like the defaults don't ship it. Make that a criteria from the start together with guidance on what defaults are acceptable for inclusion.
The underlying problem is that there is no correct way to deal with uncoordinated repositories. Maybe someone could tackle that problem. Coordination seems to have failed even in the simple cases where the idea is to be conflict-free. Maybe a brute-force test integration against all known repositories and all packages could come up with a matrix of what works together and what doesn't.
On 09/17/2012 02:58 PM, Les Mikesell wrote:
On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderned@unixmail.co.uk wrote:
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user runs 'yum update' and the repo file gets updated from the repo the user will be back at the repo's default settings regardless of how the distro may or may not have initially patched the repo file.
Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
Sole purpose of the update for repository packages is to replace *.repo file with the one with correct link, but rather then to edit file they replace it, thus defaulting any change you made.
On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
On 09/17/2012 02:58 PM, Les Mikesell wrote:
On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderned@unixmail.co.uk wrote:
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user runs 'yum update' and the repo file gets updated from the repo the user will be back at the repo's default settings regardless of how the distro may or may not have initially patched the repo file.
Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
Sole purpose of the update for repository packages is to replace *.repo file with the one with correct link, but rather then to edit file they replace it, thus defaulting any change you made.
Which doesn't really answer the question of whether locally modified config files belong to the administrator or the RPM author.... This is something important enough that it really deserves to have the 'enabled' and similar options abstracted to something under /etc/sysconfig - unless someone still holds onto the hope that one day all repositories will be coordinated and not conflict with each other. Meanwhile, I'd say such a change should come in as a .rpmnew file so you can reconcile the local edits manually (and maybe at least some of them would).
On 10/09/2012 09:37 PM, Les Mikesell wrote:
On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevicoffice@plnet.rs wrote:
On 09/17/2012 02:58 PM, Les Mikesell wrote:
On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderned@unixmail.co.uk wrote:
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user runs 'yum update' and the repo file gets updated from the repo the user will be back at the repo's default settings regardless of how the distro may or may not have initially patched the repo file.
Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
Sole purpose of the update for repository packages is to replace *.repo file with the one with correct link, but rather then to edit file they replace it, thus defaulting any change you made.
Which doesn't really answer the question of whether locally modified config files belong to the administrator or the RPM author.... This is something important enough that it really deserves to have the 'enabled' and similar options abstracted to something under /etc/sysconfig - unless someone still holds onto the hope that one day all repositories will be coordinated and not conflict with each other. Meanwhile, I'd say such a change should come in as a .rpmnew file so you can reconcile the local edits manually (and maybe at least some of them would).
I do not disagree with you on this, but I have not made yum config the way it is now, and I can not tell you if it does create .rpmnew or not. But Enabled=0 is incorporated into .repo file.
I personally would like to either have separate files for each repo entry for links and options (like Enabled), or to have options in separate database (txt file or not) that would allow much more flexible combinations and changes.
On Tue, Oct 9, 2012 at 4:14 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
On 10/09/2012 09:37 PM, Les Mikesell wrote:
On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevicoffice@plnet.rs
wrote:
On 09/17/2012 02:58 PM, Les Mikesell wrote:
On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderned@unixmail.co.uk
wrote:
Besides, your approach simply won't work. If you were to install an edited (patched) repo file set to enabled=0, the first time a user
runs
'yum update' and the repo file gets updated from the repo the user
will
be back at the repo's default settings regardless of how the distro
may
or may not have initially patched the repo file.
Hmmm, that seems like a bug. Should rpm packages clobber user
configurations?
Sole purpose of the update for repository packages is to replace *.repo file with the one with correct link, but rather then to edit file they replace it, thus defaulting any change you made.
Which doesn't really answer the question of whether locally modified config files belong to the administrator or the RPM author.... This is something important enough that it really deserves to have the 'enabled' and similar options abstracted to something under /etc/sysconfig - unless someone still holds onto the hope that one day all repositories will be coordinated and not conflict with each other. Meanwhile, I'd say such a change should come in as a .rpmnew file so you can reconcile the local edits manually (and maybe at least some of them would).
I do not disagree with you on this, but I have not made yum config the way it is now, and I can not tell you if it does create .rpmnew or not. But Enabled=0 is incorporated into .repo file.
I personally would like to either have separate files for each repo entry for links and options (like Enabled), or to have options in separate database (txt file or not) that would allow much more flexible combinations and changes.
As a person running hundreds of CentOS systems in a production environment, I'd like to note a few things:
1- No matter what package it is, and no matter from what repo is is installed, configuration files belong to the administrator, not the packager, so an rpm should NEVER replace a local config file. (this includes yum)
2- All we really need is the ability to install epel and elrepo simply, without having to hunt them down. I've done this so many times, I now include epel-release and elrepo-release (all disabled) in all my cobbler installs automatically. This is the way I feel we are best served. I use other repos too, but truly, epel is essential to most people, so epel-release, at least, should be available in the CentOS repos.
On Tue, Oct 9, 2012 at 12:23 PM, Ljubomir Ljubojevic office@plnet.rs wrote:
Sole purpose of the update for repository packages is to replace *.repo file with the one with correct link, but rather then to edit file they replace it, thus defaulting any change you made.
This isn't true, provided that the file is marked as config(noreplace) in the rpm -- which is the case for at least epel-release on EL6 which I've just verified -- local changes will not be overwritten, but instead the RPM will install the new config with a .rpmnew extension.
-Jeff
On Tue, Oct 9, 2012 at 2:14 PM, Jeff Sheltren jeff@tag1consulting.com wrote:
This isn't true, provided that the file is marked as config(noreplace) in the rpm -- which is the case for at least epel-release on EL6 which I've just verified -- local changes will not be overwritten, but instead the RPM will install the new config with a .rpmnew extension.
For anyone's reference, that is also the case for elrepo-release [ config(noreplace) in the spec ].
Akemi
On 10/09/2012 11:20 PM, Akemi Yagi wrote:
On Tue, Oct 9, 2012 at 2:14 PM, Jeff Sheltrenjeff@tag1consulting.com wrote:
This isn't true, provided that the file is marked as config(noreplace) in the rpm -- which is the case for at least epel-release on EL6 which I've just verified -- local changes will not be overwritten, but instead the RPM will install the new config with a .rpmnew extension.
For anyone's reference, that is also the case for elrepo-release [ config(noreplace) in the spec ].
Akemi
OK, thanks guys. I have not used maintainer provided repo files in couple of years, I made set of my own repo files and I exclude all *-release files so they do not meddle in my yum config.
I vote #3, do nothing. It's not like EPEL is hard to find or use. If they are wanting to use it at install time or on first boot, they can use tools like spacewalk or puppet, chef.
IMO a distribution shouldn't be in the business of coddling lazy or unknowledgeable users.
On Thursday, September 13, 2012 12:10:50 PM Matthew Patton wrote:
I vote #3, do nothing. It's not like EPEL is hard to find or use. If they are wanting to use it at install time or on first boot, they can use tools like spacewalk or puppet, chef.
IMO a distribution shouldn't be in the business of coddling lazy or unknowledgeable users.
<devils_advocate_mode>
I got a binary frontpanel I'll sell you, cheap (assuming it didn't get thrown out)! We shouldn't mollycoddle people who can't grok binary!
</devils_advocate_mode>
On 09/13/2012 07:10 PM, Matthew Patton wrote:
I vote #3, do nothing. It's not like EPEL is hard to find or use. If they are wanting to use it at install time or on first boot, they can use tools like spacewalk or puppet, chef.
Some do want to use at install time. Others just want a torrent client, or additional codecs, or a sip client and all they need is along "yum install twinkle". They have never heard of chef / puppet / PXE and they could not care less. For THOSE people a yum install epel-release && yum install $WHATEVER is what they are looking for
IMO a distribution shouldn't be in the business of coddling lazy or unknowledgeable users.
That's not a reason to spook them away though.
On Fri, Sep 14, 2012 at 12:33:54AM +0300, Manuel Wolfshant wrote:
Some do want to use at install time. Others just want a torrent client, or additional codecs, or a sip client and all they need is along "yum install twinkle". They have never heard of chef / puppet / PXE and they could not care less. For THOSE people a yum install epel-release && yum install $WHATEVER is what they are looking for
And they already have that ability by downloading the appropriate release package for the repo and installing it as per directions on the repo's site or from the centos wiki documentation.
That's not a reason to spook them away though.
This is an enterprise distro. I will paraphrase what I said earlier: if they can't figure it out perhaps it's a good time to re-think their career path.
John
On 09/13/2012 10:32 AM, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards,
I think that we should not include those repos by default. If we do, we now have to worry if they change their release files, etc.
I surely would not want it in the main distro ... maybe in extras. But I don't see that as much of an advantage unless we have it enabled by default. If we do this, we will have to maintain a release file for the repos that is different from their own release files. This will render the documentation that they have on their websites in error OR require them to change it and make it different for CentOS as compared to RHEL (that is, you must enable it if you isntalled it from here, but not if you installed it from us, etc.)
I see no reason to include this in CentOS unless what we include is exactly what is released by the repo itself, so that it works the same whether installed by our repo or theirs.
So, my vote is 3 ... and maybe 2, but not disabled as an option.
On 09/13/2012 08:49 PM, Johnny Hughes wrote:
On 09/13/2012 10:32 AM, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards,
I think that we should not include those repos by default. If we do, we now have to worry if they change their release files, etc.
Not at all. Once you include ONE version of the $repo-release file, it would get upgraded automatically once the repo is enabled. We should only care if the change(s) become incompatible. Of course, for convenience/courtesy we could/should upgrade the $repo-release once it gets upgraded "upstream". Especially as it's a piece of cake to do.
I surely would not want it in the main distro ... maybe in extras.
I am 100% in agreement with that. [base] should only contain what the upstream distro ships. but [extras] fits the bill perfectly, according to its current definition
But I don't see that as much of an advantage unless we have it enabled by default.
Disabling the repo brings only additional headaches. I already see the questions in IRC: "I've installed the release rpm but I still can not install any package from the repo. Why is that ?"
If we do this, we will have to maintain a release file for the repos that is different from their own release files.
Why is that ?? We do not need to sign them. We just ship them unaltered. Those who do not trust the centos mirrors should go to the upstream mirrors and download from there. We do not assume any other responsibility but to provide a convenient way to retrieve THIS(these) package(s). Nothing else.
This will render the documentation that they have on their websites in error OR require them to change it and make it different for CentOS as compared to RHEL (that is, you must enable it if you isntalled it from here, but not if you installed it from us, etc.)
I see no reason to include this in CentOS unless what we include is exactly what is released by the repo itself, so that it works the same whether installed by our repo or theirs.
Exactly . Ship the current $repo-release in centos-extras. Similar to what SL does for several repos and to what IUS does for EPEL as well.
On Fri, Sep 14, 2012 at 12:41:01AM +0300, Manuel Wolfshant wrote:
Disabling the repo brings only additional headaches. I already see the questions in IRC: "I've installed the release rpm but I still can not install any package from the repo. Why is that ?"
Because they've not taken the time to investigate on their own. Because they've not taken the time to read man yum.conf. Because if centos doesn't ship it support gets punted to the repo channel or mailing list in question for them to deal with.
Exactly . Ship the current $repo-release in centos-extras. Similar to what SL does for several repos and to what IUS does for EPEL as well.
Who cares what SL does? Who cares what IUS does?
John
On 09/14/2012 01:24 AM, John R. Dennison wrote:
On Fri, Sep 14, 2012 at 12:41:01AM +0300, Manuel Wolfshant wrote:
Disabling the repo brings only additional headaches. I already see the questions in IRC: "I've installed the release rpm but I still can not install any package from the repo. Why is that ?"
Because they've not taken the time to investigate on their own. Because they've not taken the time to read man yum.conf. Because if centos doesn't ship it support gets punted to the repo channel or mailing list in question for them to deal with.
Correct. But it's also correct that 90% of those users could not care less about all that reading. I do not endorse that behaviour but it's easier to help them fulfil their needs and forget about their existence by providing the release rpm than support their bashing or telling them to go read this and that.
Exactly . Ship the current $repo-release in centos-extras. Similar to what SL does for several repos and to what IUS does for EPEL as well.
Who cares what SL does? Who cares what IUS does?
I do. We are not alone in the world.
On Thu, Sep 13, 2012 at 3:33 PM, Manuel Wolfshant wolfy@nobugconsulting.ro wrote:
On 09/14/2012 01:24 AM, John R. Dennison wrote:
Exactly . Ship the current $repo-release in centos-extras. Similar to what SL does for several repos and to what IUS does for EPEL as well.
Who cares what SL does? Who cares what IUS does?
I do. We are not alone in the world.
I do, too. I have been in both CentOS and SL communities for some time now and see a number of people helping in both places. I tend to think all clones are members of a big family. Family members may have quarrels but they can help each other as well. :)
In this particular case, as already pointed out by others, the -release packages are not installed by default in SL, so for most users they are non-existent. But having the -release rpm available in SL actually benefited me more than a few times. When helping someone who needs to install a kmod package from ELRepo, for example, it is just 2 commands away; yum install elrepo-release rpm and the kmod itself.
Akemi
On 09/13/2012 10:32 AM, Karanbir Singh wrote:
- do nothing, leave things as they are.
I am included toward option 3. EPEL is easy enough, and if you want to ensure EPEL is available at first boot, one of the simplest ways is to just include these lines in a kickstart file:
repo --name=epel --baseurl=http://mirror.steadfast.net/epel/6/x86_64/
%packages epel-release
----- Original Message ----- | hi guys, | | One bit of feedback at LinuxCon this year from people was that we | should | ship epel with a lower barrier to entry. And I have mixed feelings | about | that. But I wanted to know what everyone else thinks about : | | 1) Shipping epel-release in CentOS-Extras, so its installable, usable | out of the box. | | 2) Shipping epel-release in the distro itself, with the epel repos's | enabled=false. This is the option that most people seem to want, but | I | am least keen on. | | 3) do nothing, leave things as they are. | | Ofcourse, if we do either (1) or (2) we would need to set some sort | of a | baseline standard that allows other repo's to be included as well ( | as + | if they meet the baseline standard ) |
Do nothing. There is a reason that they are not shipped with Upstream and that's because they haven't been vetted well enough to be considered "enterprise ready". If the goal is to be as compatible as possible DO THAT! Adding the EPEL repositories is a cake walk and it can be done in various ways.
Those who choose to install *any* third party repos are taking it upon themselves to ensure that the system doesn't break. This may be through the use of yum priorities, some other method or a combination of methods. I think it's just a plain bad idea.
On Thu, Sep 13, 2012 at 11:32 AM, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards, Karanbir Singh
There seems to be a chorus of "do nothings", but that clearly does not solve the problem. The point of technology is to make life easier (and wanting an easier life does not make one lazy or clueless), and since EPEL so frequently used, it stands to reason that including it does make sense.
The description of the Extras repo is:
items that provide additional functionality to CentOS without breaking upstream compatibility or updating base components
Wouldn't this package meet that description?
To Johnny's point, it seems like it should just be the package directly from the EPEL project, unmodified. But it brings up another point that using the yum-priorities plugin is often recommended, and that would not be part of the stock epel-release rpm either.
This may not be a big issue for EPEL, since they aim to "never conflict with or replace packages in the base Enterprise Linux distributions", but maybe this becomes part of the baseline standard for CentOS.
❧ Brian Mathis
On Thu, 13 Sep 2012, Brian Mathis wrote:
This may not be a big issue for EPEL, since they aim to "never conflict with or replace packages in the base Enterprise Linux distributions", but maybe this becomes part of the baseline standard for CentOS.
1. EPEL has been going through an effort to figure out where it fits, because upstream's proliferation of side products, and the main product upstream 'moving in' matter both from EPEL and from elsewhere. It is undeniable that this has caused it some heartburn to the EPEL folks -- consult its mailing list and IRC channel meeting logs for the last 6 months for details
The predicate assumption: that they aim to "never conflict with or replace packages in the base Enterprise Linux distributions"
is no longer durably accurate, any more. In looking at a mirror I maintain of SRPMS of upstream and of EPEL that I keep, I see:
./epel/6/SRPMSonly/released/SRPMS/389-admin-1.1.29-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-adminutil-1.1.15-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-console-1.1.7-1.el6.src.rpm
and
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-1.1.25-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-adminutil-1.1.14-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-console-1.1.7-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6ComputeNode/en/os/SRPMS/389-ds-base-1.2.10.2-20.el6_3.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-ds-console-1.2.6-1.el6.src.rpm
so not only does EPEL duplicate upstream's offerings, it would appear to displace them in some cases and side products. This is messy, and there is little reason to fight this fight
I understand CentOS presently may not have coverage of all at the upstream 6 series SRPMs, but that seems to me to be a more valuable way to consider moving, than pre-adding the archive of another project (EPEL) that is well-documented, and trivial as to installation. After all it is: install a package via RPM, and accept a key ... takes perhaps a minute
2. Also, EPEL is quite large -- 3815 SRPMs in their 6 tree, by last night's count. As such there are huge number of potential interactions that somehow will become CentOS responsibility sort out in the main IRC channel, because 'well, you shipped the configs' if we were to proceed to add them -- so, independently a bad idea
I would not be in favor of adding EPEL stanzas, even if not enabled
-- Russ herrold
On 09/14/2012 12:13 AM, R P Herrold wrote:
On Thu, 13 Sep 2012, Brian Mathis wrote:
This may not be a big issue for EPEL, since they aim to "never conflict with or replace packages in the base Enterprise Linux distributions", but maybe this becomes part of the baseline standard for CentOS.
- EPEL has been going through an effort to figure out where
it fits, because upstream's proliferation of side products, and the main product upstream 'moving in' matter both from EPEL and from elsewhere. It is undeniable that this has caused it some heartburn to the EPEL folks -- consult its mailing list and IRC channel meeting logs for the last 6 months for details
The predicate assumption: that they aim to "never conflict with or replace packages in the base Enterprise Linux distributions"
is no longer durably accurate, any more. In looking at a mirror I maintain of SRPMS of upstream and of EPEL that I keep, I see:
./epel/6/SRPMSonly/released/SRPMS/389-admin-1.1.29-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-adminutil-1.1.15-1.el6.src.rpm ./epel/6/SRPMSonly/released/SRPMS/389-console-1.1.7-1.el6.src.rpm
and
./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-1.1.25-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-admin-console-1.1.8-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-adminutil-1.1.14-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-console-1.1.7-1.el6.src.rpm ./redhat/rhel/SRPMSonly/6ComputeNode/en/os/SRPMS/389-ds-base-1.2.10.2-20.el6_3.src.rpm ./redhat/rhel/SRPMSonly/6Server/en/RHDirServ/SRPMS/389-ds-console-1.2.6-1.el6.src.rpm
so not only does EPEL duplicate upstream's offerings, it would appear to displace them in some cases and side products. This is messy, and there is little reason to fight this fight
I understand CentOS presently may not have coverage of all at the upstream 6 series SRPMs, but that seems to me to be a more valuable way to consider moving, than pre-adding the archive of another project (EPEL) that is well-documented, and trivial as to installation. After all it is: install a package via RPM, and accept a key ... takes perhaps a minute
That is because upstream refined their offering into multiple - even sometimes conflicting ! - channels ( RHDirServ in the example you had the kindness to provide) and not all of them are taken into account by EPEL. OTOH the EPEL guidelines are getting refined and I am 100% sure and ready to bet on a case of fine beer that the people who will see conflicts between EPEL and [base] are not among those who need the convenience of having the epel-release rpm shipped by CentOS. And even if they were, they will know how to solve them. And they would also point them to EPEL for proper solving. It happened in the past and conflicting packages were removed when needed.
- Also, EPEL is quite large -- 3815 SRPMs in their 6 tree, by
last night's count. As such there are huge number of potential interactions that somehow will become CentOS responsibility sort out in the main IRC channel, because 'well, you shipped the configs' if we were to proceed to add them -- so, independently a bad idea
I beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.
On Fri, Sep 14, 2012 at 12:50:15AM +0300, Manuel Wolfshant wrote:
I beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.
Does a pony come with that? People will want support from centos via irc and mailing list. You should really know that by now :) People are an entitled lot these days.
John
On Thu, Sep 13, 2012 at 6:27 PM, John R. Dennison jrd@gerdesas.com wrote:
On Fri, Sep 14, 2012 at 12:50:15AM +0300, Manuel Wolfshant wrote:
I beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.
Does a pony come with that? People will want support from centos via irc and mailing list. You should really know that by now :) People are an entitled lot these days.
One message with your derogatory crap is enough. Please read the whole thread and just reply once. There's no need to spew for every single message you feel the need to comment on.
❧ Brian Mathis
On Thu, Sep 13, 2012 at 06:28:52PM -0400, Brian Mathis wrote:
One message with your derogatory crap is enough. Please read the whole thread and just reply once. There's no need to spew for every single message you feel the need to comment on.
Learn to use filters. I read the whole thread. I reply to messages in a threaded order. If that doesn't meet your requirements, well, tough. I'm not here to please you, nor, frankly, do I care if you don't like it.
John
On 09/14/2012 01:27 AM, John R. Dennison wrote:
On Fri, Sep 14, 2012 at 12:50:15AM +0300, Manuel Wolfshant wrote:
I beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.
Does a pony come with that?
Nope.
People will want support from centos via irc and mailing list.
And I am VERY good in telling people "We do not support that here but you can ask at ..." in a polite way ( if I want to ) or in a rude way ( also if I want to )
You should really know that by now :)
I do. I already have 12 years of supporting crap from users
People are an entitled lot these days.
Wrong. People THINK that they are entitled. Sometime they are right, sometime they are wrong.
On Fri, Sep 14, 2012 at 01:36:12AM +0300, Manuel Wolfshant wrote:
Nope.
Bummer; I wanted one.
And I am VERY good in telling people "We do not support that here but you can ask at ..." in a polite way ( if I want to ) or in a rude way ( also if I want to )
*shrug* The point remains that shipping this is going to make users believe it is supported whatever wording you may care to use to the contrary.
Wrong. People THINK that they are entitled. Sometime they are right, sometime they are wrong.
Entitlement is always, without a single exception, wrong in an environment where they are getting something for free.
John
On 09/14/2012 01:44 AM, John R. Dennison wrote:
On Fri, Sep 14, 2012 at 01:36:12AM +0300, Manuel Wolfshant wrote:
Nope.
Bummer; I wanted one.
I know a few links on gerdesas.com from where you can download pony images free of charge :)
And I am VERY good in telling people "We do not support that here but you can ask at ..." in a polite way ( if I want to ) or in a rude way ( also if I want to )
*shrug* The point remains that shipping this is going to make users believe it is supported whatever wording you may care to use to the contrary.
And we will tell them that they are wrong. Simple enough. Join me in #centos-social and I can tell you a fresh story about a guy who needed not less than 5 minutes to understand that "The coach will take you from the gas station which is 50 m from your hotel, around the corner. The only gas station in a 5 km radius". Conversation taking place and instructions being given to him by a guide who was a native speaker of his own language so there were no translation errors involved.
Wrong. People THINK that they are entitled. Sometime they are right, sometime they are wrong.
Entitlement is always, without a single exception, wrong in an environment where they are getting something for free.
once again: we will tell them that they are wrong (when they are ). Simple enough.
On Thu, Sep 13, 2012 at 5:27 PM, John R. Dennison jrd@gerdesas.com wrote:
On Fri, Sep 14, 2012 at 12:50:15AM +0300, Manuel Wolfshant wrote:
I beg to differ here. As long as we clearly specify that we just SHIP the release rpm for users' convenience but not ENDORSE and that ALL support is to be taken from EPEL, I am sure that people will understand. A polite "please ask for help in #epel or on the epel mailing list" will definitely be all that is needed.
Does a pony come with that? People will want support from centos via irc and mailing list. You should really know that by now :) People are an entitled lot these days.
And people answer questions on the mail list too... Sometimes those answers are more useful than 'no'.
-- Les Mikesell lesmikesell@gmail.com
On Thu, 13 Sep 2012 16:32:06 +0100 Karanbir Singh mail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
<Snippyidy sniperoo>
regards,
In my opinion, it would only be suitable for the "Extras" repository. However I can see a potential problem with that. If you add one additional repository to be easily available it raises the question of
"Well, if you add their repo as an extra, why not elrepo, or rpmforge etc"
The fact is, if you allow one. Others will "want in". Thus adding more unnecessary management for CentOS team.
I can see why people would want "easy access" to these repository files. But a quick wget (or other means) is something that someone who really wants the repository is not going to be worried about. And for automated installations a minor change in a kickstart file can easily be added :-).
It is a minor inconvenience to be a "manual" step. But it in my opinion is not one which is a big hinder to anyone.
But if the CentOS team is willing to manage other repositories release files, then it should be in the Extras repository as after-all, it is an "extra" and will not be found upstream.
Just my 2 pence.
PS: I've been driving all day, so I'm tired, so expect a few grammar/spelling mistakes :-).
On Thursday, September 13, 2012 11:32:06 AM Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
I'd vote for this one, although the ScientifiLinux folk have done something similar to option 2, at least through EL5.
The argument could be made that, since the wiki already points to third party repos, a release package in Extras or even Plus that points to those repos shouldn't be a problem and would be my preferred way a change should be made, assuming a change should be made at all. If a change is made, well, there are a lot of repos out there. Particularly, if you want functional CD/DVD burning on certain chipsets with certain burners, you have to use Jorg's cdrecord, and there is a repo out there with drop-in packages that 'do the right thing' in terms of upgrading/obsoleting wodim and friends. (the repo is at city-fan.org). I'd personally like to see cdrecord packages in CentOS-Plus, but I'm also well aware of the politics behind this one..... I just had to deal with that particular issue with a VIA K8T890/8237 chipset, and wodim burnt blanks, while cdrecord works fine.... But I digress.
Also, Karanbir, did you receive my somewhat lengthy e-mail about ia64 a few days ago? If not, can you ping me privately so I can send it to the proper address? Thanks!
On 13.09.2012 16:32, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards,
I'd go with 1.
Elrepo should be considered, too.
On 13 September 2012 16:32, Karanbir Singh mail-lists@karan.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Apologies for my delayed response. (I'm still in "catch-up" mode.)
If EPEL were to tag their RPM packages such that the package ownership is perfectly clear I would vote for (1). Unfortunately EPEL declines to tag their packages, so my vote is thus (3).
Alan.
On Fri, Sep 14, 2012 at 8:46 AM, Alan Bartlett ajb@elrepo.org wrote:
If EPEL were to tag their RPM packages such that the package ownership is perfectly clear I would vote for (1). Unfortunately EPEL declines to tag their packages, so my vote is thus (3).
I think this has nothing to do with the matter of hand of: "Lots of people use EPEL (and other 3rd party repos). What can we do to make enabling those repos easier for our users?".
Please let's not go off on this tangent.
-Jeff
On 14 September 2012 16:49, Jeff Sheltren jeff@tag1consulting.com wrote:
On Fri, Sep 14, 2012 at 8:46 AM, Alan Bartlett ajb@elrepo.org wrote:
If EPEL were to tag their RPM packages such that the package ownership is perfectly clear I would vote for (1). Unfortunately EPEL declines to tag their packages, so my vote is thus (3).
I think this has nothing to do with the matter of hand of: "Lots of people use EPEL (and other 3rd party repos). What can we do to make enabling those repos easier for our users?".
Please let's not go off on this tangent.
Not a tangent, Jeff, just an explanation of why my choice is what it is.
Alan.
On Fri, Sep 14, 2012 at 9:05 AM, Alan Bartlett ajb@elrepo.org wrote:
Not a tangent, Jeff, just an explanation of why my choice is what it is.
Then would you be supportive of either inclusion option for other repos that aren't EPEL? You just think that repo tags on package names are a consideration to be taken before a certain repo is approved to be included? Or where are you going with this...?
-Jeff
On 14 September 2012 17:18, Jeff Sheltren jeff@tag1consulting.com wrote:
On Fri, Sep 14, 2012 at 9:05 AM, Alan Bartlett ajb@elrepo.org wrote:
Not a tangent, Jeff, just an explanation of why my choice is what it is.
Then would you be supportive of either inclusion option for other repos that aren't EPEL? You just think that repo tags on package names are a consideration to be taken before a certain repo is approved to be included? Or where are you going with this...?
Provoke me all you like, I will not take the bait.
Please note that:
(1) I replied to KB's initial message and nothing more. (2) It is unclear, to me, whom you were quoting with --
"Lots of people use EPEL (and other 3rd party repos). What can we do to make enabling those repos easier for our users?".
-- certainly not KB or Johnny Hughes. Thus your inclusion of that quote (if it actually is a quote from somewhere above and not something you just decided to type) is actually tangential.
Alan.
On Fri, Sep 14, 2012 at 9:35 AM, Alan Bartlett ajb@elrepo.org wrote:
Provoke me all you like, I will not take the bait.
Alan, I'm not trying to provoke you at all; I'm sorry if it came across that way. I'm trying to move this conversation along so that we can figure out the next action -- even if that next action turns out to be "do nothing".
Please note that:
(1) I replied to KB's initial message and nothing more. (2) It is unclear, to me, whom you were quoting with --
"Lots of people use EPEL (and other 3rd party repos). What can we do to make enabling those repos easier for our users?".
That was me paraphrasing KB's initial post. All words are my own. That's the discussion I thought we were having here, am I mistaken?
My question to you about allowing other repos was intended to see if your negative response around EPEL was simply a judgement on EPEL, or if you are saying it's not CentOS' place to include any repo files/packages for 3rd party repos.
-Jeff
On 14 September 2012 17:40, Jeff Sheltren jeff@tag1consulting.com wrote:
On Fri, Sep 14, 2012 at 9:35 AM, Alan Bartlett ajb@elrepo.org wrote:
Provoke me all you like, I will not take the bait.
Alan, I'm not trying to provoke you at all; I'm sorry if it came across that way.
Apology accepted. :)
I'm trying to move this conversation along so that we can figure out the next action -- even if that next action turns out to be "do nothing".
Please take a moment to look at your posting to this list of 1549 hours UTC that appears, to me, to be a direct reply to my response to KB's initial post. You were concerned about tangents (when there was none), yet now you appear to want to take discussion off on one about my opinions regarding other repositories.
The discussion, here, is about EPEL. Because they do not tag their packages and -- thank you Russ for providing some examples -- as EPEL will overwrite certain distribution packages, my choice out of the three options KB initially suggested is (3).
Discussions concerning other repositories (and my opinions thereof) are for another time and another thread/conversation.
Alan.
On Fri, 14 Sep 2012, Alan Bartlett wrote:
The discussion, here, is about EPEL. Because they do not tag their packages and -- thank you Russ for providing some examples
I wrote the tool to 'see' potentials for over-writes after their mailing list had a thread that raised the concern. It became clear that as they were not systematically looking broadly enough for potential conflicts to suit my tastes. There are many more than the ones I posted
As a result (and actually before), the only way I consider adding EPEL as a binary archive, is with a blanket 'exclude', and per package 'includepkgs' settings. I am fine with using it as a source of SRPMs for local custom solutions for customers where I control the dependencies and over-writes, by and large (there are some exceptions)
Your tastes may vary, but the idea of adding the repository and letting a admin 'choose' to enable it will, to my thinking, result in people adding it fully enabled and without care. We see this in IRC all the time, that people post pastebins that have EPEL, and rpmforge, and ART, and more, all turned on with no awareness of why "CENTOS is broken!!"
Not a good idea. Who needs the reputational damage? Not CentOS
-- Russ herrold
On 09/14/2012 10:49 AM, Jeff Sheltren wrote:
On Fri, Sep 14, 2012 at 8:46 AM, Alan Bartlett ajb@elrepo.org wrote:
If EPEL were to tag their RPM packages such that the package ownership is perfectly clear I would vote for (1). Unfortunately EPEL declines to tag their packages, so my vote is thus (3).
I think this has nothing to do with the matter of hand of: "Lots of people use EPEL (and other 3rd party repos). What can we do to make enabling those repos easier for our users?".
Please let's not go off on this tangent.
-Jeff
I am trying to understand how this:
yum install epel-repo
(and installing an rpm maintained by CentOS that is disabled by default, and requires editing after install)
is any easier for users than this:
yum install http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
(and getting an enabled repo file with no editing requried)
The repo is still installed in one step, and no editing is required.
I find it hard to understand how us including repo rpms, which have the potential to become outdated and require editing after install are somehow easier than installing from originator. We are also going to install the user's pki files (which are in most repo "release" files), etc.
I am fine to put the rpms in the extras repo if people really think this is a benefit, and maybe I am not seeing something, but to me this does not seem to help much.
What am I missing?
On Friday, September 14, 2012 02:08:40 PM Johnny Hughes wrote:
I am trying to understand how this:
yum install epel-repo
is any easier for users than this:
yum install http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
Assuming osuosl's mirror is up... but anyway, 'yum --enablerepo=extras install epel-release' (with the repo in epel-release enabled, that is, a direct mirror of what is in EPEL itself) is a whole lot easier to type correctly and a whole lot easier for someone, who is likely to be unfamiliar with Fedora's website and mirroring system and difficulty in finding anything but the current Fedora Desktop LiveCD, to find and to understand.
Also, if epel-release were to be shipped in both C5 and C6's Extras for all supported arches, then the EPEL install instructions are the same and consistent among all CentOS releases, no 'find the right EPEL release and arch' required.
If I want to go to the EPEL repo, it is actually easier to find from the CentOS Wiki than from the Fedora Project website's home page.
But, Alan has a good point about the complete lack of a distro tag, and Russ is completely correct about EPEL shipping packages that do supercede upstream packages without an easy to see differentiator in the package name. But both of those points are valid whether CentOS ships epel-release (as is, rsync'd straight from EPEL) from Extras or not. Shipping epel-release just makes it easier for users to get to EPEL.
On 09/14/2012 08:42 PM, Lamar Owen wrote:
On Friday, September 14, 2012 02:08:40 PM Johnny Hughes wrote:
I am trying to understand how this:
yum install epel-repo
is any easier for users than this:
yum install http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
Assuming osuosl's mirror is up... but anyway, 'yum --enablerepo=extras install epel-release' (with the repo in epel-release enabled, that is, a direct mirror of what is in EPEL itself) is a whole lot easier to type correctly and a whole lot easier for someone, who is likely to be unfamiliar with Fedora's website and mirroring system and difficulty in finding anything but the current Fedora Desktop LiveCD, to find and to understand.
Also, if epel-release were to be shipped in both C5 and C6's Extras for all supported arches, then the EPEL install instructions are the same and consistent among all CentOS releases, no 'find the right EPEL release and arch' required.
If I want to go to the EPEL repo, it is actually easier to find from the CentOS Wiki than from the Fedora Project website's home page.
But, Alan has a good point about the complete lack of a distro tag, and Russ is completely correct about EPEL shipping packages that do supercede upstream packages without an easy to see differentiator in the package name. But both of those points are valid whether CentOS ships epel-release (as is, rsync'd straight from EPEL) from Extras or not. Shipping epel-release just makes it easier for users to get to EPEL.
I was long time out of loop for personal reasons, so I missed this discussion when it happened.
People that asked that EPEL repo package is to be included in CentOS distribution are Home users that would like to setup CentOS as file (and other) server for home or even Desktop use. Since Ubuntu is much easier in that respect, to complicated procedure will just direct them to ditch CentOS and use Ubuntu instead.
For popularization of CentOS as a Desktop use, that is path to larger Server use, thing should be much easier. Adding epel-release (and elrepo-release) would be excellent step forward for popularization of CentOS among general population as one of the most stable Linux distros today.
Example: My friend says that he would like to reinstall his Windows system with Linux and asks my what Linux distro he should use, and if I could help him install and maintain it. And he wants full shebang, with codecs etc.
Now, the difference between
yum install epel-repo
and
Open browser search for third party repository via google on centos site find EPEL on page locate server navigate to find proper rpm file explain how he should copy it find out why his copying does not download the needed file (he has not selected entire link, etc)
yum install http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
(or similar procedure).
You can not dictate the second command over the phone, and without setting up mailing client, and navigating noob is even more time consuming.
So adding EPEL (and elrepo) package(s) would help popularize CentOS amongst general population, unless someone does not want CentOS to be popular so he does not have to teach total noobs how to use it.
Suggestions:
1. centos-release should be altered to incorporate Priority=X line so the people using other repositories could use 3rd party repositories more safely, even if *-release packages of 3rd party repos will not be added.
2. CentOS project could build "Desktop" or "Friendly" ISO's with added epel-release and elrepo-release files that would stop discouraging "Desktop" people from using CentOS and driving them to other distros.
And I vote for *-release file to exist in CentOS-Extras repository without installing them by default.
On Fri, Sep 14, 2012 at 2:08 PM, Johnny Hughes johnny@centos.org wrote:
I am trying to understand how this: yum install epel-repo (and installing an rpm maintained by CentOS that is disabled by default, and requires editing after install)
is any easier for users than this: yum install \ http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm (and getting an enabled repo file with no editing requried)
The repo is still installed in one step, and no editing is required.
I find it hard to understand how us including repo rpms, which have the potential to become outdated and require editing after install are somehow easier than installing from originator. We are also going to install the user's pki files (which are in most repo "release" files), etc.
I am fine to put the rpms in the extras repo if people really think this is a benefit, and maybe I am not seeing something, but to me this does not seem to help much.
What am I missing?
The difference is that you need to track down that URL to begin with. That's a significant amount of friction which consists of: switch to your web browser, locate the EPEL site, navigate the site to find the download link, copy/paste the download link into your terminal window. Most of that requires a bunch of mousing around, waiting for pages to load, etc...
A simple "yum install epel-release" is quick and requires no context switches or anything else, which significantly reduces latency.
I think the "CentOS edited" thing is probably out of the picture, as you'd then be just creating your own custom RPM anyway, which would be much more overhead.
As far as the packages becoming outdated, you are right, and I think part of the assumption here is that a CentOS repo with these packages would be automatically mirrored from their parent repos. I just figured that was a given.
❧ Brian Mathis
On 14.9.2012 17:46, Alan Bartlett wrote:
On 13 September 2012 16:32, Karanbir Singh mail-lists-XASut8F7j/3YtjvyW6yDsg@public.gmane.org wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Apologies for my delayed response. (I'm still in "catch-up" mode.)
If EPEL were to tag their RPM packages such that the package ownership is perfectly clear I would vote for (1). Unfortunately EPEL declines to tag their packages, so my vote is thus (3).
Your tag argument seems different from all other arguments :-)
Throughout this thread people are saying 1 or 2 or 3 but what is with that baseline standards Karanbir mentioned? In my opinion this is the most important part of this. And the most difficult maybe.
...snip Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard ) ...snap
Do not ask if EPEL should be included or not but get clear what the standards should be for whatever repo. Maybe EPEL or maybe no repo in the world could catch up with this standards, but well then, lets choose 3.
Sorry if I am not entitled :-)
My vote is for 1 , maybe even 2 :) It is truly usable and it is the first thing on new installs ;)
Regards, Marko On Thu, 13 Sep 2012, Karanbir Singh wrote:
hi guys,
One bit of feedback at LinuxCon this year from people was that we should ship epel with a lower barrier to entry. And I have mixed feelings about that. But I wanted to know what everyone else thinks about :
- Shipping epel-release in CentOS-Extras, so its installable, usable
out of the box.
- Shipping epel-release in the distro itself, with the epel repos's
enabled=false. This is the option that most people seem to want, but I am least keen on.
- do nothing, leave things as they are.
Ofcourse, if we do either (1) or (2) we would need to set some sort of a baseline standard that allows other repo's to be included as well ( as + if they meet the baseline standard )
regards,
I always install epel as the first thing I do after installing a centos system, and I don't really agree with those that say you're lazy if you don't install the hard way. I personally would prefer to see the epel-release package as part of the base install. This allows us to install with yum, that seems the easiest to me.
That's my vote.
-
Akemi Yagi -
Alan Bartlett -
Alessandro Ren -
Brian Mathis -
David Hrbáč -
Jake Shipton -
James A. Peltier -
Jeff Sheltren -
John R. Dennison -
Johnny Hughes -
Karanbir Singh -
Kevin Stange -
Lamar Owen -
Les Mikesell -
Ljubomir Ljubojevic -
Manuel Wolfshant -
Marko A. Jennings -
Marko Bevc -
Markus Falb -
Matthew Patton -
me＠tdiehl.org -
Mike Schmidt -
Ned Slider -
Nux! -
R P Herrold -
R P Herrold -
Trevor Hemsley