FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 09-14-2012, 06:48 PM
Christoph Galuschka
 
Default 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 )
>

I add EPEL to all C6 installations because there is a certain set of
packages which I need from that repo. But this is done by a script which
sord of customizes the C6 installation to my needs.

So basically I'm fine doing this by hand.

Long story short: options 3 and 1 (in this order) get my vote. To be
honest I never thought about other repos being part of CentOS by default.

Christoph
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-14-2012, 08:02 PM
Markus Falb
 
Default Shipping an EPEL release

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 :
>>
>> 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.
>
> 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 :-)
--
Kind Regards, Markus Falb

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-14-2012, 08:28 PM
R P Herrold
 
Default Shipping an EPEL release

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-14-2012, 09:09 PM
Brian Mathis
 
Default Shipping an EPEL release

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-15-2012, 12:14 AM
Mike Schmidt
 
Default Shipping an EPEL release

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.
--
Mike SCHMIDT
CTO*


Intello Technologies Inc.
mike.schmidt@intello.com

Canada: 1-888-404-6261 x320
USA: 1-888-404-6268 x320

Mobile: 514-409-6898

www.intello.com




_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-15-2012, 04:04 PM
Les Mikesell
 
Default Shipping an EPEL release

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 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@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-15-2012, 04:09 PM
Les Mikesell
 
Default Shipping an EPEL release

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-15-2012, 06:01 PM
Ned Slider
 
Default Shipping an EPEL release

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.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-16-2012, 04:19 PM
Les Mikesell
 
Default Shipping an EPEL release

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.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-16-2012, 06:05 PM
Ned Slider
 
Default Shipping an EPEL release

On 16/09/12 17:19, Les Mikesell wrote:
> 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.
>

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.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 08:04 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org