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.
|