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-16-2012, 06:26 PM
Manuel Wolfshant
 
Default Shipping an EPEL release

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


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 09-16-2012, 07:08 PM
Ned Slider
 
Default Shipping an EPEL release

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

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

On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider <ned@unixmail.co.uk> wrote:
> >
>> If it is included, it can be patched. Debian/ubuntu do this somewhat
>> sensibly but there you have to make a one-time selection to enable the
>> extra repos. I think it is nicer to keep the alternative ones (except
>> maybe EPEL) disabled.
>>
>
> As a repo provider, if you patch it you can support it as it's no longer
> what I ship. I don't want the extra support load when you break what I ship.

If setting a repo file to enabled=0 breaks something, then no one
should be using it in the first place. As for support, does that mean
you'll come fix my box when a different 3rd part repo adds a package
with the same name and the packages clobber each other during updates?
If not, how is not having your support any different?

> Which is pretty much the same response you'll hear from CentOS every
> time someone posts with a system running a non-CentOS kernel.

And yet, everyone has policies that keep them from accepting all
packages into one repository. Lovely... And worse, where the point
of the repo is to supply updated packages, they often aren't renamed
and intentionally conflict with others.

> IMHO that's not what CentOS wants here. It's certainly not what 3rd
> party repo providers would want either.

I'm sure it isn't. But it would serve the users that need packages
they each refuse to accept.

> Besides, your approach simply won't work. If you were to install an
> edited (patched) repo file set to enabled=0, the first time a user runs
> 'yum update' and the repo file gets updated from the repo the user will
> be back at the repo's default settings regardless of how the distro may
> or may not have initially patched the repo file.

Hmmm, that seems like a bug. Should rpm packages clobber user configurations?

> It's simply not your config file to alter so if you don't like the
> defaults don't ship it. Make that a criteria from the start together
> with guidance on what defaults are acceptable for inclusion.

The underlying problem is that there is no correct way to deal with
uncoordinated repositories. Maybe someone could tackle that problem.
Coordination seems to have failed even in the simple cases where the
idea is to be conflict-free. Maybe a brute-force test integration
against all known repositories and all packages could come up with a
matrix of what works together and what doesn't.

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-09-2012, 07:23 PM
Ljubomir Ljubojevic
 
Default Shipping an EPEL release

On 09/17/2012 02:58 PM, Les Mikesell wrote:
> On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider<ned@unixmail.co.uk> wrote:
>>>
>
>> Besides, your approach simply won't work. If you were to install an
>> edited (patched) repo file set to enabled=0, the first time a user runs
>> 'yum update' and the repo file gets updated from the repo the user will
>> be back at the repo's default settings regardless of how the distro may
>> or may not have initially patched the repo file.
>
> Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
>

Sole purpose of the update for repository packages is to replace *.repo
file with the one with correct link, but rather then to edit file they
replace it, thus defaulting any change you made.

--

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

On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic <office@plnet.rs> wrote:
> On 09/17/2012 02:58 PM, Les Mikesell wrote:
>> On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider<ned@unixmail.co.uk> wrote:
>>>>
>>
>>> Besides, your approach simply won't work. If you were to install an
>>> edited (patched) repo file set to enabled=0, the first time a user runs
>>> 'yum update' and the repo file gets updated from the repo the user will
>>> be back at the repo's default settings regardless of how the distro may
>>> or may not have initially patched the repo file.
>>
>> Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
>>
>
> Sole purpose of the update for repository packages is to replace *.repo
> file with the one with correct link, but rather then to edit file they
> replace it, thus defaulting any change you made.

Which doesn't really answer the question of whether locally modified
config files belong to the administrator or the RPM author.... This
is something important enough that it really deserves to have the
'enabled' and similar options abstracted to something under
/etc/sysconfig - unless someone still holds onto the hope that one day
all repositories will be coordinated and not conflict with each other.
Meanwhile, I'd say such a change should come in as a .rpmnew file so
you can reconcile the local edits manually (and maybe at least some of
them would).

--
Les Mikesell
lesmikesell@gmail.com
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-09-2012, 08:08 PM
Ljubomir Ljubojevic
 
Default Shipping an EPEL release

On 09/14/2012 08:42 PM, Lamar Owen wrote:
> On Friday, September 14, 2012 02:08:40 PM Johnny Hughes wrote:
>> I am trying to understand how this:
>>
>> yum install epel-repo
>
>> is any easier for users than this:
>
>> yum install
>> http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm
>
> Assuming osuosl's mirror is up... but anyway, 'yum --enablerepo=extras install epel-release' (with the repo in epel-release enabled, that is, a direct mirror of what is in EPEL itself) is a whole lot easier to type correctly and a whole lot easier for someone, who is likely to be unfamiliar with Fedora's website and mirroring system and difficulty in finding anything but the current Fedora Desktop LiveCD, to find and to understand.
>
> Also, if epel-release were to be shipped in both C5 and C6's Extras for all supported arches, then the EPEL install instructions are the same and consistent among all CentOS releases, no 'find the right EPEL release and arch' required.
>
> If I want to go to the EPEL repo, it is actually easier to find from the CentOS Wiki than from the Fedora Project website's home page.
>
> But, Alan has a good point about the complete lack of a distro tag, and Russ is completely correct about EPEL shipping packages that do supercede upstream packages without an easy to see differentiator in the package name. But both of those points are valid whether CentOS ships epel-release (as is, rsync'd straight from EPEL) from Extras or not. Shipping epel-release just makes it easier for users to get to EPEL.

I was long time out of loop for personal reasons, so I missed this
discussion when it happened.

People that asked that EPEL repo package is to be included in CentOS
distribution are Home users that would like to setup CentOS as file (and
other) server for home or even Desktop use. Since Ubuntu is much easier
in that respect, to complicated procedure will just direct them to ditch
CentOS and use Ubuntu instead.

For popularization of CentOS as a Desktop use, that is path to larger
Server use, thing should be much easier. Adding epel-release (and
elrepo-release) would be excellent step forward for popularization of
CentOS among general population as one of the most stable Linux distros
today.

Example: My friend says that he would like to reinstall his Windows
system with Linux and asks my what Linux distro he should use, and if I
could help him install and maintain it. And he wants full shebang, with
codecs etc.

Now, the difference between

yum install epel-repo

and

Open browser
search for third party repository via google on centos site
find EPEL on page
locate server
navigate to find proper rpm file
explain how he should copy it
find out why his copying does not download the needed file (he has not
selected entire link, etc)

yum install
http://ftp.osuosl.org/pub/fedora-epel/6/i386/epel-release-6-7.noarch.rpm

(or similar procedure).


You can not dictate the second command over the phone, and without
setting up mailing client, and navigating noob is even more time consuming.

So adding EPEL (and elrepo) package(s) would help popularize CentOS
amongst general population, unless someone does not want CentOS to be
popular so he does not have to teach total noobs how to use it.


Suggestions:

1. centos-release should be altered to incorporate Priority=X line so
the people using other repositories could use 3rd party repositories
more safely, even if *-release packages of 3rd party repos will not be
added.

2. CentOS project could build "Desktop" or "Friendly" ISO's with added
epel-release and elrepo-release files that would stop discouraging
"Desktop" people from using CentOS and driving them to other distros.

And I vote for *-release file to exist in CentOS-Extras repository
without installing them by default.


--

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

On 10/09/2012 09:37 PM, Les Mikesell wrote:
> On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic<office@plnet.rs> wrote:
>> On 09/17/2012 02:58 PM, Les Mikesell wrote:
>>> On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider<ned@unixmail.co.uk> wrote:
>>>>>
>>>
>>>> Besides, your approach simply won't work. If you were to install an
>>>> edited (patched) repo file set to enabled=0, the first time a user runs
>>>> 'yum update' and the repo file gets updated from the repo the user will
>>>> be back at the repo's default settings regardless of how the distro may
>>>> or may not have initially patched the repo file.
>>>
>>> Hmmm, that seems like a bug. Should rpm packages clobber user configurations?
>>>
>>
>> Sole purpose of the update for repository packages is to replace *.repo
>> file with the one with correct link, but rather then to edit file they
>> replace it, thus defaulting any change you made.
>
> Which doesn't really answer the question of whether locally modified
> config files belong to the administrator or the RPM author.... This
> is something important enough that it really deserves to have the
> 'enabled' and similar options abstracted to something under
> /etc/sysconfig - unless someone still holds onto the hope that one day
> all repositories will be coordinated and not conflict with each other.
> Meanwhile, I'd say such a change should come in as a .rpmnew file so
> you can reconcile the local edits manually (and maybe at least some of
> them would).
>

I do not disagree with you on this, but I have not made yum config the
way it is now, and I can not tell you if it does create .rpmnew or not.
But Enabled=0 is incorporated into .repo file.

I personally would like to either have separate files for each repo
entry for links and options (like Enabled), or to have options in
separate database (txt file or not) that would allow much more flexible
combinations and changes.

--

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

On Tue, Oct 9, 2012 at 4:14 PM, Ljubomir Ljubojevic <office@plnet.rs> wrote:


On 10/09/2012 09:37 PM, Les Mikesell wrote:

> On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic<office@plnet.rs> *wrote:

>> On 09/17/2012 02:58 PM, Les Mikesell wrote:

>>> On Sun, Sep 16, 2012 at 1:05 PM, Ned Slider<ned@unixmail.co.uk> * wrote:

>>>>>

>>>

>>>> Besides, your approach simply won't work. If you were to install an

>>>> edited (patched) repo file set to enabled=0, the first time a user runs

>>>> 'yum update' and the repo file gets updated from the repo the user will

>>>> be back at the repo's default settings regardless of how the distro may

>>>> or may not have initially patched the repo file.

>>>

>>> Hmmm, that seems like a bug. *Should rpm packages clobber user configurations?

>>>

>>

>> Sole purpose of the update for repository packages is to replace *.repo

>> file with the one with correct link, but rather then to edit file they

>> replace it, thus defaulting any change you made.

>

> Which doesn't really answer the question of whether locally modified

> config files belong to the administrator or the RPM author.... *This

> is something important enough that it really deserves to have the

> 'enabled' and similar options abstracted to something under

> /etc/sysconfig - unless someone still holds onto the hope that one day

> all repositories will be coordinated and not conflict with each other.

> * *Meanwhile, I'd say such a change should come in as a .rpmnew file so

> you can reconcile the local edits manually (and maybe at least some of

> them would).

>



I do not disagree with you on this, but I have not made yum config the

way it is now, and I can not tell you if it does create .rpmnew or not.

But Enabled=0 is incorporated into .repo file.



I personally would like to either have separate files for each repo

entry for links and options (like Enabled), or to have options in

separate database (txt file or not) that would allow much more flexible

combinations and changes.


*As a person running hundreds of CentOS systems in a production environment, I'd like to note a few things:

1-
No matter what package it is, and no matter from what repo is is
installed, configuration files belong to the administrator, not the
packager, so an rpm should NEVER replace a local config file. (this includes yum)

2- All
we really need is the ability to install epel and elrepo simply,
without having to hunt them down. I've done this so many times, I now
include epel-release and elrepo-release (all disabled)* in all my cobbler installs
automatically. This is the way I feel we are best served. I use other repos too, but truly, epel is essential to most people, so epel-release, at least, should be available in the CentOS repos.

--


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 10-09-2012, 09:14 PM
Jeff Sheltren
 
Default Shipping an EPEL release

On Tue, Oct 9, 2012 at 12:23 PM, Ljubomir Ljubojevic <office@plnet.rs> wrote:
> Sole purpose of the update for repository packages is to replace *.repo
> file with the one with correct link, but rather then to edit file they
> replace it, thus defaulting any change you made.
>

This isn't true, provided that the file is marked as config(noreplace)
in the rpm -- which is the case for at least epel-release on EL6 which
I've just verified -- local changes will not be overwritten, but
instead the RPM will install the new config with a .rpmnew extension.

-Jeff
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 10-09-2012, 09:20 PM
Akemi Yagi
 
Default Shipping an EPEL release

On Tue, Oct 9, 2012 at 2:14 PM, Jeff Sheltren <jeff@tag1consulting.com> wrote:

> This isn't true, provided that the file is marked as config(noreplace)
> in the rpm -- which is the case for at least epel-release on EL6 which
> I've just verified -- local changes will not be overwritten, but
> instead the RPM will install the new config with a .rpmnew extension.

For anyone's reference, that is also the case for elrepo-release [
config(noreplace) in the spec ].

Akemi
_______________________________________________
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 09:01 PM.

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