On 01/17/2014 10:06 AM, 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? Ideally by eliminating package duplication for the SIG/repos who work with us, but that's an ivory tower goal that's likely unattainable. It will likely be a combination of working with SIGs to coordinate and cooperate, changing to SCL builds where possible and appropriate, and documentation to better educate the users. SCL builds provide a nice name-spaced way to have multiple versions of the same packages installed. For example, python27, python33, multiple php and httpd versions, etc. All of which are mostly impractical with the older rpm packaging style (see php and httpd for example). This is by no means a silver bullet, but it does solve a fair chunk of the issue. > 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. These could easily be scl enabled packages. Keep in mind we have a scenario very much like this with the Clear and Neth groups, who seem to be very interested in working with us. > 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. I'm not sure this is the best example to address your point, but I do understand your meaning. This problem is not unique to CentOS, and I don't consider it to be a core distribution or board problem. The SIGs and Variants are up to their respective communities to maintain and keep current. If they falter, we'll certainly try to help but we're not going to take over the maintenance of a failing SIG. > ----------------------------------- > 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. Enabled, we can likely accommodate, and I'll discuss this with the others. Priorities, I'm not sold on. > ---------------------------------- > > 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. You seem to be quite passionate for the laptop/desktop users. Why not participate or create a SIG with that target audience? You could tailor this exactly as you wish with the packages (assuming legally distributable) you wish. > 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. There is a skip_if_unavailable option, but I'm not sure that's what you're getting at. I believe fedora was also working on some sort of package library that would allow you to search directly. Perhaps this is something we could see about appropriating from them for our own uses. > 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). > The formats and guidelines we're establishing will apply as equally as possible to all groups. However, I would much prefer overlay release files, similar to how there's an epel-release, elrepo-release, gluster-release, etc. This way one can 'at-a-glance' see what's in play with a simple 'yum list installed *-release' > 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? > Certainly. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77