[CentOS-devel] Repository structures for SIG and variants in the future

Manuel Wolfshant wolfy at nobugconsulting.ro
Fri Jan 17 17:37:22 UTC 2014


On 01/17/2014 06:06 PM, Ljubomir Ljubojevic wrote:
> On 01/17/2014 02:35 PM, Jim Perrin wrote:
>> On 01/17/2014 07:08 AM, Manuel Wolfshant wrote:
>>
>>> make it 5 or 10, please. one might want to supersede base packages with
>>> ones from private/local repos. hplip for instance was such a candidate
>>> for a long time, my printers were not supported by the stock version of
>>> hplip from EL5 and I had to compile a newer one from fedora. and at the
>>> time I was not yet relying on include/excludepkgs
>>>
>>
>> This touches exactly on the point for why I don't want to include
>> priorities by default. To make it useful for repos that provide newer
>> software than what exists in base/updates (php, httpd, libvirt,
>> whatever), you're automatically working against priorities. It doesn't
>> matter if it's for a local repository or for a SIG.
>>
>>
> So how do you intend to solve this without priorities? Especially if
> there is a need for some packages to be compiled with different flags?
>
> One example is for those using Virtualmin. Virtualmin provides http,
> postfix and few other packages compiled little differently (different
> flags) then RH does, in their own repository. So if both repositories
> are of same priority, when RH publishes newer version it is
> automatically an update to modified version. And that can brake things
> until Virtualmin releases their own version. If we "hide" RH versions
> with higher priority to Virtualmin packages then nothing can be broken.
guess what ? you can  use exclude=httpd in centos-base.repo and 
includepkgs=httpd in the other one and you have no need for priorities



> -----------------------------------
> But, as I said, for now I will be happy with "Priorities=" and
> "Enabled=" for every repo's config. It will make many things easier,
> like creating script to change those numbers per users request (you do
> not have to host it). Adding them to every new config (after
> centos-release is updated) is not desired.
do you mean something like yum-config-manager ?


> ----------------------------------
>
> With new opportunities creating CentOS Variants, I already thought of
> few things I would ask of yum project to incorporate, to further provide
> out-of-the-box experience for Variants users.
>
> With all of my suggestions so far, I think something like "Skip=" for
> every repo would be useful for those who use their internal mirrors.
> If you set "Enabled=0" for some repo, using "--enablerepo=*" will enable
> it. Another use is to have installed but disabled one or more 3rd party
> repos, so you can quickly locate and install some needed package. No
> need for search around internet, double checking.
>
> So if you want to use internal mirror, you have two options:
>
> 1. "Enabled=0" for CentOS-Base.repo repos, where you loose flexibility
> of simple "--enablerepo=*" when you want to find something.
--enablerepo=* is anyway a bad idea because it will also enable at least 
all vault repos and the media repo. leaving aside that delay for 
accessing the vault, attempting to access the media repository will most 
probably lead to a nice fail


>
> 2. Removing CentOS-Base.repo to backup folder or commenting out entire
> file. Both options needing root's manual intervention (sudo yum
> authorization does not extend to editing files).
but sudo yum-config-manager does




More information about the CentOS-devel mailing list