This thread started off-list before I was approved for this list. Thanks for the prompt reply Troy. I hope you don't mind that I'm moving this to on-list. I wrote: >> Since SL-5.0, the yum package has required yum-autoupdate. However, >> there is nothing in yum-autoupdate that is actually needed by yum. >> >> yum-autoupdate contains /etc/cron.daily/yum.cron which is a script >> written by Troy. It works fine, but for various reasons such as >> ease of reconfiguration and only generating emails if an update >> fails, I would prefer to to use the package yum-cron from EPEL. >> This package has a file conflict with yum-autoupdate from SL. >> >> So I request that yum should not require yum-autoupdate and that >> yum-autoupdate be made optional (default yes) in the installer. On Mon, 2 Mar 2009, Troy Dawson replied: > I'd really really really (is that enough really's) not like to take > out the requires yum-autoupdate. I understand that you want at least one autoupdate mechanism to be installed but I think that can be achieved simply by making one of them installed by default along with yum in the base install. In fact, thinking about this, I think it makes more sense to give people the option at install time to choose yum-autoupdate, yum-updatesd or neither. Some people, e.g. cluster admins, do not want any auto updates enabled as they prefer to do controlled updates at scheduled times. I know they can do "chkconfig yum off" but they wouldn't have to worry about this if the package is never installed. It seems to me that if package A works just fine without capability B, then A should not require B. Some package providing B can be installed by default, but consenting adults should have the option to choose to have no package that provides B. In fact in this case, the dependencies are backwards. yum-autoupdate and yum-updatesd both need yum but adding that requirement to the existing packages would cause a circular dependency. Try continued: > But, I have no problem putting in the yum-cron from EPEL and marking > that it "provides yum-autoupdate", thus removing the conflict. That is > what we did with yum-updatesd. I see that you have already done this in SL-5.3-RC2 but I think it's a bad idea for a couple of reasons. (1) Having the same packages multiple repositories causes problems. This is even more so if they are not identical. We already have this problem with alpine, R, graphviz, numpy and some perl modules in EPEL. ie. If you installed alpine in SL-5.2 you would have version 1.1 . But if you enabled EPEL, then alpine will be updated to 2.00 from that repo. The situation is worse with R which as different sub-packages in EPEL. Of course you can get around these problems using yum-protectbase, or yum-priorities, or excluding the packages from one or the other with "exclude=" in the repo files. But all of these involve editing yum repo files which we'd prefer not to ahve to do. One of the guidelines of EPEL is to not have package clashes with RHEL so when a package is added to RHEL it is removed from EPEL [1]. Obviously this doesn't guarantee that EPEL is compatable with SL or CentOS, but it ensures that there won't be duplication between EPEL and packages from TUV. For us SL users, there are packages in EPEL that we find useful (e.g. cernlib, ...) so at least trying to miminise the clashes seems like a good idea. (2) The other part of this that I think is a bad idea is that you have several packages providing a certain capability (yum-autoupdate) but one of them is actually named yum-autoupdate. The usual way of using alternatives, is for the capability to be a different name than any of the packages. e.g. sendmail and postfix both provide mta (mail-transport agent). Packages then need either sendmail or postfix have mta as their requirement and the alternatives scheme is used for determining which is active. Anyway, thanks again for considering my suggestion and apologies for the length of this post. Kel Raywood TRIUMF [1] The EPEL maintainers are currently trying to figure out how to deal with java-1.6.0-openjdk which has been added to RHEL without the sub-package java-1.6.0.-openjdk-plugin, the browser plugin.