Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 179376 - Improvement for yum daily cron job
Improvement for yum daily cron job
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2006-01-30 13:13 EST by Piergiorgio Sartor
Modified: 2014-01-21 17:53 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-02 01:23:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Piergiorgio Sartor 2006-01-30 13:13:52 EST
Description of problem:
yum has a daily cron job which updates what needs to be updated,
without any advice.
It would be maybe better (as discussed in many places) to have
to configuration possibility to choose between update or simply
notify (that updates are available).

Version-Release number of selected component (if applicable):
from latest development it is version 2.5.1-2

Additional info:
Googling around I found this:


It seems to fulfill all the possible requirements, automatic update
or notification, in a quite configurable way (using /etc/sysconfig).
It might be nice to have this enhancement in the next FC5 release.
Comment 1 Seth Vidal 2006-02-02 01:23:39 EST
look in /etc/yum/yum-daily.yum

that's what yum runs in the daily cron job.
just edit that file and make it do whatever you want.


in there seems the most likely candidate.
Comment 2 Piergiorgio Sartor 2006-02-02 02:45:14 EST
(In reply to comment #1)
> look in /etc/yum/yum-daily.yum
> that's what yum runs in the daily cron job.
> just edit that file and make it do whatever you want.
> check-update
> in there seems the most likely candidate.

Well, clearly that is possible.
Unfortunately, sometimes, configuration files are changed on updates.
Having a _long_ script /etc/yum/yum-daily.yum might be a problem
when this file is changed by successive yum/rpm processing.
Not to mention that yum itself is updated without questions in first,
maybe this is also not wanted.
It would be possible, of course, to call an external script from
/etc/yum/yum-daily.yum, but once again this would require some
modification in the system (where to put the script? What about
several PCs? All to be modified in a sensible way... Which kinf
of scripting capabilites has yum?).
In other words, it is of course possible, the issue here is that it
would be _better_ (IMHO) to provide this as default feature, instead
of leaving it to the user.
In fact this entry was an "enhancement" request, not a bug report.
I hope you will consider the possibility to introduce this script
in the upcoming FC5.
Thanks again.
Comment 3 Seth Vidal 2006-02-02 06:15:57 EST
%config(noreplace) %{_sysconfdir}/%{name}/*.yum

the file is marked as config noreplace. If you change it subsequent package
updates will not reset your changes to that file.

config file change mgmt is beyond the scope of yum and for series of programs
should be handled by other mechanisms.
Comment 4 Piergiorgio Sartor 2006-02-02 14:14:23 EST
Uhm, I'm quite surprised (and disappointed) from this discussion.
My idea was that all this open development was also about _improvement_.

I perfectly know that config files could be "noreplace" (even if this might
cause other issues), like I know how to change/add/substitute a script in
order to do what I want.

Sorry to say, don't take it wrongly, but I think you miss the point here.
The fact is that the link I reported shows a clear _improvement_ to the
current handling of the yum cron job.
It has all the current feature plus more configurability/flexibility and
I do not see any drawbacks.
So, I hoped, it could be a nice evolution of the current, quite poor I must
say, yum cron job.

If there are no disavantages, why not to use it?

Unless there is a "workload" problem for the maintainer, but then it would
be much simpler to say so instead of proposing solution that will require
some user effort (which is always possible).

Again, sorry, I do not intend to offend anyone.

Still hope to see the update.


Note You need to log in before you can comment on or make changes to this bug.