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

[Ljubomir Ljubojevic]

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.

Same rule will apply to any package any Variant will have to compile 
with different flags, including CentOSPlus kernels. If someone uses 
CentOSPlus kernel because regular RH kernel does not have drivers for 
their hardware, and happens that CentOSPlus kernel is not released the 
same time as regular kernel (even 1-5h can make a difference), problem 
may arise where update to regular kernel fails and we have a unhappy 
user. With newbies around (I hope we attract in greater numbers), that 
can be troublesome.

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

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.

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

When internal mirror is not accessible, and you made changes to 
CentOS-Base.repo or moved it, then you need to revert the changes in 
order to use official mirrors. Again, root's manual intervention is needed.

So in order to have 1. but without "--enablerepo=*" problems, 
introduction of "Skip=1" when "Enabled=0" would allow "--enablerepo=*" 
use with many disabled and/or (currently) not accessible repositories. 
Or maybe "--enableactiverepo=*" or something like that.

Working around current "restrictions" in CentOS concerning 3rd party 
repository manipulation is possible, but I think CentOS-Core should be 
as close to Variants as possible in terms of repository syntax and use, 
so we do not have to build (in-house or 3rd party) additional layer over 
centos-release package or replace it all together (for Variants).

I will go over to yum mailing list and post my ideas there and see what 
they say, and maybe you can talk about this with them on OfficeHours?


-- 
Ljubomir Ljubojevic
(Love is in the Air)
PL Computers
Serbia, Europe

StarOS, Mikrotik and CentOS/RHEL/Linux consultant