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, 09:31 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
> On Thu, Sep 13, 2012 at 8:32 AM, Karanbir Singh<mail-lists@karan.org> wrote:
>> hi guys,
>>
>> One bit of feedback at LinuxCon this year from people was that we should
>> ship epel with a lower barrier to entry. And I have mixed feelings about
>> that. But I wanted to know what everyone else thinks about :
>>
> EPEL is the first thing I add to most servers I manage (CentOS or
> RHEL). I would like the added convenience of having it included by
> default -- either of the options you listed would be OK for me from
> that perspective. However, including it in the base OS doesn't make a
> lot of sense to me as we look for a way to scale it out to include
> other repos as well. Adding those to CentOS Extras seems like the way
> to go to make it a low barrier of entry to enable repos (I assume with
> some sort of qualification before we include them).
>
> I have to say though, I rarely use CentOS Extras, and I'd be more
> likely to stick with adding EPEL in a kickstart file. I understand
> that's not for everyone though.
>
> <snip from kickstart>
> repo --name=epel --baseurl=http://ftp.osuosl.org/pub/fedora-epel/5/x86_64/
> [...]
> %packages
> @base
> epel-release
> [...]
> </snip>
>
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.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:33 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

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

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.

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

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 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 :
>>>
> 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_s oftware_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@tdiehl.org Spamtrap address me123@tdiehl.org
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:50 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

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.

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-13-2012, 09:53 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

On 09/14/2012 12:44 AM, me@tdiehl.org wrote:
> On Fri, 14 Sep 2012, Manuel Wolfshant wrote:
>
>> On 09/13/2012 06:42 PM, Jeff Sheltren wrote:
>>> On Thu, Sep 13, 2012 at 8:32 AM, Karanbir 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 :
>>>>
>> But for those who do not have prior
>> knowledge, like it or not, yum install epel-release is way easier than
>> to follow "go read our wiki page on adding 3rd party repos and pay
>> attention to priorities". Yes, I know, they should read/learn. But
>> helping them by excluding the "hunt for epel-release and install it"
>> part will not hurt.
> And yum install http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7
> is hard?
No, it is not. But I've seen more than once people getting confused by
the fact that the package name changes over time or by confusion between
the release version and the distro version for which it is intended.

>
> Googling "install epel-release" gets the following url:
> http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_the_EPEL_s oftware_repository.3F
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.
>

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

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

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

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

On Thu, Sep 13, 2012 at 6:27 PM, John R. Dennison <jrd@gerdesas.com> wrote:
> On Fri, Sep 14, 2012 at 12:50:15AM +0300, Manuel Wolfshant wrote:
>> I beg to differ here. As long as we clearly specify that we just SHIP
>> the release rpm for users' convenience but not ENDORSE and that ALL
>> support is to be taken from EPEL, I am sure that people will understand.
>> A polite "please ask for help in #epel or on the epel mailing list" will
>> definitely be all that is needed.
>
> Does a pony come with that? People will want support from centos via
> irc and mailing list. You should really know that by now People are
> an entitled lot these days.


One message with your derogatory crap is enough. Please read the
whole thread and just reply once. There's no need to spew for every
single message you feel the need to comment on.


❧ Brian Mathis
_______________________________________________
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:46 PM.

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