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.