[CentOS-devel] Shipping an EPEL release
office at plnet.rs
Tue Oct 9 20:14:45 UTC 2012
On 10/09/2012 09:37 PM, Les Mikesell wrote:
> On Tue, Oct 9, 2012 at 2:23 PM, Ljubomir Ljubojevic<office at 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 at 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.
(Love is in the Air)
Google is the Mother, Google is the Father, and traceroute is your
StarOS, Mikrotik and CentOS/RHEL/Linux consultant
More information about the CentOS-devel