On Mon, May 2, 2016 at 12:29 PM, Konstantin Olchanski
<[log in to unmask]> wrote:
> On Sun, May 01, 2016 at 12:49:01PM -0400, Nico Kadel-Garcia wrote:
>> >> > Use the much better yum-autoupdate from CERN instead:
>> >> > http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29
>>
>> The directions and tools are also entirely incompatible with older
>> versions of Scientific Linux, such as SL 6 or the still supported SL 5.
>>
>
> (on-list reply)
>
> I think there is a misunderstanding.
>
> The intent of my instructions is to restore in SL7/CentOS7 the functionality that has
> been always present in SL5 and SL6, where yum-autoupdate was always present
> and is easy to enable via "chkconfig yum-autuopdate on":
>
> SL5: -rw-r--r-- 1 root root 27524 Dec 10  2014 6x/x86_64/os/Packages/yum-autoupdate-2-6.6.noarch.rpm
> SL6: -rw-r--r-- 1 root root 9111 Oct  8  2012 5x/x86_64/SL/yum-autoupdate-1.2-3.SL.noarch.rpm
>
> This package is absent in SL7 and CentOS7, so I have to pull it in from CERN linux CC-7. I agree
> it would have been cleaner to install the CC-7 yum repository, but that could have accidentally
> pulled some unwanted CERN packages.

If you need to activate a third party repository that overlaps with
your standard repositories, a more useful approach that allows updates
more gracefully is to install a copy of the ".repo" file for that
repository and disable all the repositories by default so they can be
activated only when specifically requested. This works well for
CentOS/RHEL/SL repositories that have packages missing from each
other, and worked well for RPMforge and EPEL before RPMforge became
moribund. I've also used it extensively with RHEL systems to privide
access to RHEL or SL add-on component repositories, or internal
repositories that may overlap with upstream repos.

> (to Nico)
>
> If you do not like the yum-autoupdate script, you do not have to use it,
> but there is no need to dump on the tool or/and on my instructions.

You've also improved the instructions to use standard repos rather
than private repository URL's, that's a good move. Thank you.

>> ... Replacing a live, standard upstream kernel for such a small reason is
>> always a bad idea. ...
>>
>
> You are mistaken, my instructions do not replace the standard kernel.

You're correct. More checking shows that the "yum-kernel-module" is a
kernel module management tool for yum, not a kernel module itself. It
was also apparently discarded by the upstream RHEL operating system
after RHEL 5, and it's apparently not in the base SL 7 distribution.
I've no idea why you think it's still needed. Perhaps you could
explain?

My ranting about using systemd for an update daemon, rather than just
a cron job, still stand.