FAQ
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,

--
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
GnuPG Key : http://www.karan.org/publickey.asc

Search Discussions

  • Jeff Sheltren at Sep 13, 2012 at 11:42 am

    On Thu, Sep 13, 2012 at 8: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 :
    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
  • Manuel Wolfshant at Sep 13, 2012 at 5:31 pm

    On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
    On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singhwrote:
    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.
  • Me at Sep 13, 2012 at 5:44 pm

    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 Singhwrote:
    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_the_EPEL_software_repository.3F

    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 me at tdiehl.org Spamtrap address me123 at tdiehl.org
  • Manuel Wolfshant at Sep 13, 2012 at 5:53 pm

    On 09/14/2012 12:44 AM, me at 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 Singhwrote:
    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.
    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.
  • John R. Dennison at Sep 13, 2012 at 6:36 pm

    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
    --
    Like its politicians and its wars, society has the teenagers it deserves.

    -- John Boynton Priestley (1894-1984), English playwright, novelist, and
    broadcaster
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/0583e3fd/attachment.bin
  • Manuel Wolfshant at Sep 13, 2012 at 7:04 pm

    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.
  • Brian Mathis at Sep 13, 2012 at 6:31 pm

    On Thu, Sep 13, 2012 at 5:44 PM, 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 Singhwrote:
    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_the_EPEL_software_repository.3F

    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
  • Trevor Hemsley at Sep 13, 2012 at 11:54 am

    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 :

    1) 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
  • Ned Slider at Sep 13, 2012 at 12:48 pm

    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 :

    1) 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 :-)
  • Alessandro Ren at Sep 13, 2012 at 12:52 pm

    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.
  • Manuel Wolfshant at Sep 13, 2012 at 5:24 pm

    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 :

    1) 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".
  • John R. Dennison at Sep 13, 2012 at 5:28 pm

    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
    --
    We can be knowledgeable with other men's knowledge but we cannot be wise
    with other men's wisdom.

    -- Michel Montaigne (1533-1592), essayist, Essais, Book 1, Chapter 25
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/4073b073/attachment.bin
  • Les Mikesell at Sep 15, 2012 at 12:04 pm

    On Thu, Sep 13, 2012 at 4:28 PM, John R. Dennison wrote:
    "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.

    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.


    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ned Slider at Sep 15, 2012 at 2:01 pm

    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.
  • Les Mikesell at Sep 16, 2012 at 12:19 pm

    On Sat, Sep 15, 2012 at 1:01 PM, Ned Slider 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.


    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ned Slider at Sep 16, 2012 at 2:05 pm

    On 16/09/12 17:19, Les Mikesell wrote:
    On Sat, Sep 15, 2012 at 1:01 PM, Ned Sliderwrote:
    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.
  • Manuel Wolfshant at Sep 16, 2012 at 2:26 pm

    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 Sliderwrote:
    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.
  • Ned Slider at Sep 16, 2012 at 3:08 pm

    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 Sliderwrote:
    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.
  • Les Mikesell at Sep 17, 2012 at 8:58 am

    On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider 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.


    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ljubomir Ljubojevic at Oct 9, 2012 at 3:23 pm

    On 09/17/2012 02:58 PM, Les Mikesell wrote:
    On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderwrote:
    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.


    --


    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe


    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Les Mikesell at Oct 9, 2012 at 3:37 pm

    On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic wrote:
    On 09/17/2012 02:58 PM, Les Mikesell wrote:
    On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderwrote:
    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).


    --
    Les Mikesell
    lesmikesell at gmail.com
  • Ljubomir Ljubojevic at Oct 9, 2012 at 4:14 pm

    On 10/09/2012 09:37 PM, Les Mikesell wrote:
    On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevicwrote:
    On 09/17/2012 02:58 PM, Les Mikesell wrote:
    On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderwrote:
    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.


    --


    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe


    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Mike Schmidt at Oct 9, 2012 at 5:00 pm

    On Tue, Oct 9, 2012 at 4:14 PM, Ljubomir Ljubojevic wrote:

    On 10/09/2012 09:37 PM, Les Mikesell wrote:
    On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevicwrote:
    On 09/17/2012 02:58 PM, Les Mikesell wrote:
    On Sun, Sep 16, 2012 at 1:05 PM, Ned Sliderwrote:
    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.


    --
    *Mike SCHMIDT
    **CTO
    Intello Technologies Inc.
    **mike.schmidt at intello.com*
    *Canada: 1-888-404-6261 x320
    USA: 1-888-404-6268 x320
    Mobile: 514-409-6898
    www.intello.com*
    *
    *
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20121009/b38798b4/attachment.html
  • Jeff Sheltren at Oct 9, 2012 at 5:14 pm

    On Tue, Oct 9, 2012 at 12:23 PM, Ljubomir Ljubojevic 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
  • Akemi Yagi at Oct 9, 2012 at 5:20 pm

    On Tue, Oct 9, 2012 at 2:14 PM, Jeff Sheltren 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
  • Ljubomir Ljubojevic at Oct 9, 2012 at 5:40 pm

    On 10/09/2012 11:20 PM, Akemi Yagi wrote:
    On Tue, Oct 9, 2012 at 2:14 PM, Jeff Sheltrenwrote:
    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.




    --


    Ljubomir Ljubojevic
    (Love is in the Air)
    PL Computers
    Serbia, Europe


    Google is the Mother, Google is the Father, and traceroute is your
    trusty Spiderman...
    StarOS, Mikrotik and CentOS/RHEL/Linux consultant
  • Κiζs飛ゞ揚 at Sep 13, 2012 at 12:04 pm
    Who are you? publishers?



    ------------------ Original ------------------
    From: "Karanbir Singh"<mail-lists@karan.org>;
    Date: Thu, Sep 13, 2012 11:32 PM
    To: "The CentOS developers mailing list."<centos-devel@centos.org>;

    Subject: [CentOS-devel] Shipping an EPEL release



    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,

    --
    Karanbir Singh
    +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
    ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax
    GnuPG Key : http://www.karan.org/publickey.asc
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20120914/de9c93aa/attachment.html
  • Matthew Patton at Sep 13, 2012 at 12:10 pm
    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.
  • Lamar Owen at Sep 13, 2012 at 5:04 pm

    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>
  • Manuel Wolfshant at Sep 13, 2012 at 5:33 pm

    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.
  • John R. Dennison at Sep 13, 2012 at 6:21 pm

    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
    --
    In a free society the state does not administer the affairs of men. It
    administers justice among men who conduct their own affairs.

    -- Walter Lippmann (1889-1974), "An Inquiry into the Principles of the
    Good Society" (1937)
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/ec3f8478/attachment.bin
  • David Hrbáč at Sep 13, 2012 at 12:20 pm

    Dne 13.9.2012 17:32, Karanbir Singh napsal(a):
    3) do nothing, leave things as they are.
    My vote.
    DH
  • Marko A. Jennings at Sep 13, 2012 at 12:44 pm
    My vote is to leave things as they are.

    Marko Jennings
  • Κiζs飛ゞ揚 at Sep 13, 2012 at 1:03 pm
    You have been unsubscribed from the CentOS-devel mailing list !!!


    Why should that be?

    How do I send mail to everyone?
    ------------------ Original ------------------
    From: "David Hrb??"<david-lists@hrbac.cz>;
    Date: Fri, Sep 14, 2012 00:20 AM
    To: "centos-devel"<centos-devel@centos.org>;

    Subject: Re: [CentOS-devel] Shipping an EPEL release



    Dne 13.9.2012 17:32, Karanbir Singh napsal(a):
    3) do nothing, leave things as they are.
    My vote.
    DH
    _______________________________________________
    CentOS-devel mailing list
    CentOS-devel at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos-devel/attachments/20120914/ce5b0941/attachment.html
  • Johnny Hughes at Sep 13, 2012 at 1:49 pm

    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 :

    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,
    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 262 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/8c84bb87/attachment.bin
  • Manuel Wolfshant at Sep 13, 2012 at 5:41 pm

    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 :

    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,
    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.
  • John R. Dennison at Sep 13, 2012 at 6:24 pm

    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
    --
    Basic research is when I am doing what I don't know what I am doing.

    -- Wernher von Braun (1912-1977), German-born rocket scientist,
    in an interview in the New York Times, 16 December 1957
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/80983101/attachment.bin
  • Manuel Wolfshant at Sep 13, 2012 at 6:33 pm

    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.
  • Akemi Yagi at Sep 13, 2012 at 8:51 pm

    On Thu, Sep 13, 2012 at 3:33 PM, Manuel Wolfshant 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
  • Kevin Stange at Sep 13, 2012 at 2:03 pm

    On 09/13/2012 10:32 AM, Karanbir Singh wrote:
    3) 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

    --
    Kevin Stange
    Chief Technology Officer
    Steadfast Networks
    http://steadfast.net
    Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 259 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/3dddc617/attachment.bin
  • James A. Peltier at Sep 13, 2012 at 2:15 pm

    ----- 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.

    --
    James A. Peltier
    Manager, IT Services - Research Computing Group
    Simon Fraser University - Burnaby Campus
    Phone : 778-782-6573
    Fax : 778-782-3045
    E-Mail : jpeltier at sfu.ca
    Website : http://www.sfu.ca/itservices
    http://blogs.sfu.ca/people/jpeltier

    Success is to be measured not so much by the position that one has reached
    in life but as by the obstacles they have overcome. - Booker T. Washington
  • Brian Mathis at Sep 13, 2012 at 3:32 pm

    On Thu, Sep 13, 2012 at 11: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 :

    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,
    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
  • R P Herrold at Sep 13, 2012 at 5:13 pm

    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
  • Manuel Wolfshant at Sep 13, 2012 at 5:50 pm

    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.
    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
    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.

    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 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.
  • John R. Dennison at Sep 13, 2012 at 6:27 pm

    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
    --
    I begin by taking. I shall find scholars later to demonstrate my perfect right.

    -- Euripides (c 480 BC - 406 BC), Greek playwright, Suppliants
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/9afc32ad/attachment.bin
  • Brian Mathis at Sep 13, 2012 at 6:28 pm

    On Thu, Sep 13, 2012 at 6:27 PM, 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? 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
  • John R. Dennison at Sep 13, 2012 at 6:40 pm

    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
    --
    We can only be said to be alive in those moments when our hearts are conscious
    of our treasures.

    -- Thornton Wilder (17 April 1897 - 7 December 1975) American playwright
    and novelist
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/1cf19009/attachment.bin
  • Manuel Wolfshant at Sep 13, 2012 at 6:36 pm

    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.
  • John R. Dennison at Sep 13, 2012 at 6:44 pm

    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
    --
    "Whenever two people meet, there are really six people present. There is each
    man as he sees himself, each man as the other person sees him, and each man
    as he really is."

    -- William James
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20120913/ee6ade0d/attachment.bin
  • Manuel Wolfshant at Sep 13, 2012 at 7:11 pm

    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.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase