Kelvin Raywood wrote:
> 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.

Hi Kel,
I can understand your argument about the autoupdate.  It's not going to happen 
in SL5, but I understand it.  We'll look at it in SL6.
The reasoning for it is to force someone to make the decision of turning it 
off, and not make that decision accidental.  If someone can accidentally turn 
off their automatic updates during the install, then I don't want it happening. 
  And by accidental, I mean physically unclicking the yum-autoupdate.    If you 
don't think that's an accident, then you haven't maintained a distro before.
There are about 25 other arguments behind that one on why I'm not going to 
change the requirement.  I wasn't kidding when I said I really really really 
don't want to change it.  I sympathize with you, but please sympathize for me 
as well.

As far as taking packages out because they are in EPEL.  That just doesn't make 
sense.  If you want a pure RHEL clone, use CentOS.  Because if we start pulling 
packages out because they are in EPEL, dag, atrpms, and centos-extra's ... 
well, plain CentOS is what you have.
I'm not forcing you to use EPEL.  And if you install the yum-conf-epel you 
should also pull in yum-priorities, which prevents EPEL's packages from 
overwriting the SL one's.  But yum-conf-epel was only put into the release for 
a convenience, not as a way to steer the direction of Scientific Linux.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________