(replying to several)
Sometime after saying that what Ed suggested and that it worked. I
discovered that it was overkill. I launched "apper", and it failed
because "PackageKit" was not running. Having read the postings since my
Dec. 18 message...
(Tom said)
> But as I discovered, if you disable that, and simply run
>
> dnf update
>
> it will never think there are any updates available. ...
Having seen that, to do the weekly patches this morning, I first did
systemctl unmask packagekit.service
and then (after rebooting) proceeded to do
dnf upgrade --refresh
There were problems with python2 and hplip. But I assumed those
problems were not related to PackageKit.
(Let's leave those 2 problems aside for now; I'll get to those later. I
am aware of the hplip thread.)
Apart from those 2 problems, the patch worked. Apper and software also
now appear to work, and I'm not getting any requests for permission to
update.
Let me approach this as a good software engineer should: *requirements*
first! Here are my requirements for my workstation:
The only times there should be any checking for updates is:
* when I manually enter certain dnf commands. In this case, the
checking should be a part of the dnf command's execution. So my weekly
patches should only require "dnf upgrade --refresh", and that entered
only once.
* when rkhunter runs (I think it automatically checks for updates to its
database).
I don't know how to determine if any other checking is going on. Do I
already have what I want, or do I need to do one or more of what was
suggested by a few of you:
(Samuel) But there is also a cron job for dnf that updates the metadata
regularly (daily?). If that's a concern for you, you can disable that
one as well.
(Ed) By "cron job" don't you mean dnf-makecache.timer in systemd?
(Samuel) systemctl disable dnf-makecache.timer
(Joe) systemctl stop dnf-makecache.timer
(Samuel) Or run "systemctl disable --now dnf-makecache.timer" to do both
at once.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
