Instead, hardcode the protection of dnf in libdnf. This way, DNF 5 will
be able to uninstall DNF 4.
= changelog =
msg: Allow dnf to be removed by DNF 5
type: enhancement
This reverts commit 352b174a0b.
adding the condition %{witout dnf5_obsoletes_dnf} to keep the
unprotected directive for chroots that build dnf with rpm
option with=dnf5_obsoletes_dnf
Move command provides to python3-dnf
In fedora distribution there are two packages that depends on those
provides therefor the movement of those provide to real provider should
help with transition to dnf5 or at least it allows to use the old dnf4
after obsolete of dnf package.
Add ability in DNF Automatic to automatically trigger a reboot after an
upgrade. The `reboot` option supports three settings: ``never`` does not
reboot the system (current behavior). ``when-changed`` triggers a reboot
after any upgrade. ``when-needed`` triggers a reboot only when rebooting
is necessary to apply changes, such as when systemd or the kernel is
upgraded. The `reboot_command` option allows customizing the command
used to reboot (default is `shutdown -r`).
= changelog =
msg: Add `reboot` option to DNF Automatic
type: enhancement
resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2124793
Apparently, it was never intended for "do we deal with FS-backed
argument?" check to do a possibly problematic[*] prefix check on
the whole home dir path, so get this right and also simplify the
function statement as it makes do without any conditionals.
[*] This is three-fold:
- first and foremost: whole NSS machinery would be, in accordance
with Tilde Expansion, hard at work to figure out whether there
is a '*' user (which is a long shot to say the least), possibly
even accidentally crashing the process (as happened to me,
leading to this very fix: https://bugzilla.redhat.com/1929936),
- then, being entirely redundant (as long as $HOME always resolves
to the absolute address) with the preceding slash-prefix-check,
hence a futile work could be performed in a negative case,
- and finally, not capturing the actual intention of user to
complete "~/foo.rpm" (package starting with tilde would not
be offered in the completion as originally intended, IMHO)
Running dnf in containers or other minimal systems does not usr nor
require python3. Yet without /usr/bin/python3, completion does not
work. This is due to a bad path in the code which checks for the path
to python in _dnf_set_python_exec().
The system-python name was changed to platform-python at some point.
Using dnf completion on a system without python3 should work using the
same python that dnf itself uses, /usr/libexec/platform-python.
Arguably, this path should be set via @PYTHON_EXECUTABLE@ as it is for
bin/dnf for consistency and correctness.
Changes all systemd timers of the automatic systemd services to start at
6AM with a randomized delay of one hour. This changes the timing so that
it happens at a predictable time every day (before the business hours).
Removes the AccuracySec=1s, the default is one minute. We don't
need a one second accuracy and the higher default is meant to conserve
energy (probably negligible here).
Adds the Persistent=true option so that the time of the last run is
stored on disk and the unit is run as soon as possible if the event
expired while the machine was turned off.
https://bugzilla.redhat.com/show_bug.cgi?id=1754609
With the introduction of a default set of aliases in da52d0ee8e,
we are supposed to install the alias files. However, the change was incomplete.
This fixes the installation of those aliases.
By moving the randomised delay from `dnf-automatic` to the systemd timers that call `dnf-automatic`, we get more accurate information from `systemctl list-timers`, and we allow `dnf-automatic` to be triggered immediately with, e.g., `systemctl start dnf-automatic-install.service`
The timer does not need the network. The service needs it. Move the
After=network-online.target line to the service file. Wants=network-online.target
is still in .timer, which means that the network-online.target and services that
implement it will be pulled in from the .timer and started eagerly. But there is
no ordering, so they only need to finish before the .service is started.
Keeping the ordering dependency between timer and network-online.target means
that network-online.target is ordered before multi-user.target, which is wrong,
because it delays multi-user.target for no good reason.
This patch changes the ordering so that the service will be started
{10 minutes after boot} or when the network is available, whatever is
later, and not 10 minutes after {the network is available and the
boot is finished, whatever is later}.
Tested by running an affected system without AdamWill's patch but with this patch,
and confirming that the ordering loop is gone. (AdamWill's patch is correct on its
own, because putting this timer and the associated service in basic.target is
bonkers.)
Follow-up for 3144280dc7.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
In ee96304, `After=network-online.target` was added to the
dnf-makecache.timer service definition. However, it was already
`WantedBy=basic.target`. These two requests are contradictory
in Fedora and probably most distributions, as it seems that
network-online.target requires NetworkManager.service, and
NetworkManger.service requires basic.target. systemd is forced
to break this loop somehow: my testing suggests that it usually
does so by throwing dnf-makecache.timer out of the process, but
sometimes does it by throwing NetworkManager out of the process,
resulting in the network unexpectedly not coming up. See
https://bugzilla.redhat.com/show_bug.cgi?id=1600823 for more.
This commit resolves this simply having dnf-makecache.timer
WantedBy multi-user.target, not basic.target. I don't think we
*really* want DNF refreshing its caches in what is basically a
recovery environment, after all, and NetworkManager itself is
WantedBy multi-user.target, so if you actually only boot to
basic.target, there is no network up at all after boot (I've
tested this).
There are other options (e.g. dropping the After network-online
ordering and just trusting the Wants and the ten-minute startup
delay to be sufficient), but we certainly should resolve this
one way or another.
Resolves: rhbz#1600823
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The completion helper command is a bit long. Split the command and
options into local variables to improve readability.
Closes: #894
Approved by: m-blaha
The completion helper can hang indefinitely waiting for user input
(which the user cannot see). The --assumeno option ensures any prompts
are answered negatively.
Using the --nogpgcheck option avoids the helper downloading gpgkeys for
repos which have repo_gpgcheck=1 set. This can speed up the completion
quite a bit.
Lastly, redirect input from /dev/null to ensure the completion_helper
command knows it has no controlling tty on which to wait for input.
Closes: #894
Approved by: m-blaha
This should speed up the generation of the package list list a little bit.
Signed-off-by: Martin Kutlak <mkutlak@redhat.com>
Closes: #894
Approved by: m-blaha
dnf list pe TabTab wasn't auto-completing packages. It will now
suggest installed or available packages.
Autocompletion for dnf list installed/available will only suggest installed/available
packages onwards.
https://bugzilla.redhat.com/show_bug.cgi?id=1270295
Signed-off-by: Martin Kutlak <mkutlak@redhat.com>
Closes: #894
Approved by: m-blaha
Petr Písař