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