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-13-2012, 05:49 PM
Johnny Hughes
 
Default Shipping an EPEL release

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.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 06:03 PM
Kevin Stange
 
Default Shipping an EPEL release

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

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 06:15 PM
"James A. Peltier"
 
Default Shipping an EPEL release

----- Original Message -----
| hi guys,
|
| One bit of feedback at LinuxCon this year from people was that we
| should
| ship epel with a lower barrier to entry. And I have mixed feelings
| about
| that. But I wanted to know what everyone else thinks about :
|
| 1) Shipping epel-release in CentOS-Extras, so its installable, usable
| out of the box.
|
| 2) Shipping epel-release in the distro itself, with the epel repos's
| enabled=false. This is the option that most people seem to want, but
| I
| am least keen on.
|
| 3) do nothing, leave things as they are.
|
| Ofcourse, if we do either (1) or (2) we would need to set some sort
| of a
| baseline standard that allows other repo's to be included as well (
| as +
| if they meet the baseline standard )
|

Do nothing. There is a reason that they are not shipped with Upstream and that's because they haven't been vetted well enough to be considered "enterprise ready". If the goal is to be as compatible as possible DO THAT! Adding the EPEL repositories is a cake walk and it can be done in various ways.

Those who choose to install *any* third party repos are taking it upon themselves to ensure that the system doesn't break. This may be through the use of yum priorities, some other method or a combination of methods. I think it's just a plain bad idea.

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

On Thu, Sep 13, 2012 at 11:32 AM, Karanbir Singh <mail-lists@karan.org> wrote:
> hi guys,
>
> One bit of feedback at LinuxCon this year from people was that we should
> ship epel with a lower barrier to entry. And I have mixed feelings about
> that. But I wanted to know what everyone else thinks about :
>
> 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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 08:10 PM
Jake Shipton
 
Default Shipping an EPEL release

On Thu, 13 Sep 2012 16:32:06 +0100
Karanbir Singh <mail-lists@karan.org> wrote:

> hi guys,
>
> One bit of feedback at LinuxCon this year from people was that we
> should ship epel with a lower barrier to entry. And I have mixed
> feelings about that. But I wanted to know what everyone else thinks
> about :
> <Snippyidy sniperoo>
>
> regards,
>

In my opinion, it would only be suitable for the "Extras" repository.
However I can see a potential problem with that. If you add one
additional repository to be easily available it raises the question of

"Well, if you add their repo as an extra, why not elrepo, or rpmforge
etc"

The fact is, if you allow one. Others will "want in". Thus adding more
unnecessary management for CentOS team.

I can see why people would want "easy access" to these repository
files. But a quick wget (or other means) is something that someone who
really wants the repository is not going to be worried about. And for
automated installations a minor change in a kickstart file can easily
be added :-).

It is a minor inconvenience to be a "manual" step. But it in my
opinion is not one which is a big hinder to anyone.

But if the CentOS team is willing to manage other repositories release
files, then it should be in the Extras repository as after-all, it is an
"extra" and will not be found upstream.

Just my 2 pence.

PS: I've been driving all day, so I'm tired, so expect a few
grammar/spelling mistakes :-).

--
Jake Shipton (JakeMS)
GPG Key: 0xE3C31D8F
GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:04 PM
Lamar Owen
 
Default Shipping an EPEL release

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

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

On Thursday, September 13, 2012 11:32:06 AM Karanbir Singh wrote:
> hi guys,
>
> One bit of feedback at LinuxCon this year from people was that we should
> ship epel with a lower barrier to entry. And I have mixed feelings about
> that. But I wanted to know what everyone else thinks about :
>
> 1) Shipping epel-release in CentOS-Extras, so its installable, usable
> out of the box.

I'd vote for this one, although the ScientifiLinux folk have done something similar to option 2, at least through EL5.

The argument could be made that, since the wiki already points to third party repos, a release package in Extras or even Plus that points to those repos shouldn't be a problem and would be my preferred way a change should be made, assuming a change should be made at all. If a change is made, well, there are a lot of repos out there. Particularly, if you want functional CD/DVD burning on certain chipsets with certain burners, you have to use Jorg's cdrecord, and there is a repo out there with drop-in packages that 'do the right thing' in terms of upgrading/obsoleting wodim and friends. (the repo is at city-fan.org). I'd personally like to see cdrecord packages in CentOS-Plus, but I'm also well aware of the politics behind this one..... I just had to deal with that particular issue with a VIA K8T890/8237 chipset, and wodim burnt blanks, while cdrecord works fine.... But I digress.

Also, Karanbir, did you receive my somewhat lengthy e-mail about ia64 a few days ago? If not, can you ping me privately so I can send it to the proper address? Thanks!
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:24 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

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

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:28 PM
"John R. Dennison"
 
Default Shipping an EPEL release

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
_______________________________________________
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 11:25 AM.

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