`SetConstIterator::operator*` returns a reference, this is visible in
cpp and the user behaves accordingly.
In Python the user expects automatic memory management, the object
returned from query iterator should be valid as long as there is a
reference to it.
To ensure this add swig typemaps that copy the returned object.
It works because none of the queries (RepoQeury, GroupQuery,
EnvironmentQuery) store the actual data. They just store some kind of
proxy (RepoWeakPtr or wrapped libsolv ids) so if we copy the RepoWeakPtr
it still points to the same Repo object.
The PackageQuery and AdvisoryQuery return by value even in cpp so they
don't have this problem.
The problem is that the assignment statement in Python never copies
objects, this means that when we get a reference (returned by
`SetConstIterator::operator*()` to internal query object it is valid
only as long as the query lives.
This means that without additional changes this is a problem for
`RepoQuery`, `GroupQuery` and `EnvironmentQuery`. For me it doesn't
crash with `RepoQuery` (probably due to different memory layout) but it
is caught when run with Sanitizers or valgrind.
To verify with valgrind:
from `dnf5/test/python3/libdnf5` do
`$ PROJECT_BINARY_DIR=../../../build \
PROJECT_SOURCE_DIR=../../../ valgrind python3.13 -m unittest \
repo.test_repo_query.TestRepoQuery.test_repo_query`
This behavior is unexpected in Python, it should manage livetimes
automatically.
When `from_repo_ids` is specified, we want to perform `upgrade` and
`distro-sync` only for packages installed from the specified
repositories.
Using UPGRADE_ALL, UPGRADE_ALL_MINIMAL, and DISTROSYNC_ALL is not
possible in this case.
The `add_up_down_distrosync_to_goal` function now properly takes
`GoalJobsSettings::set_from_repo_ids` into account. This ensures
that goal operations respect the specified repository origins.
The `add_remove_to_goal` and `add_reinstall_to_goal` functions
now properly account for `GoalJobsSettings::set_from_repo_ids`.
This ensures that goal operations respect the specified repository
origins.
Adds the `--installed-from-repo=` option to `dnf5 repoquery` `dnf5 list`
and `dnf5 info` commands. This new filter allows users to narrow down
the displayed installed packages to only those that originated from
a specified repositories ID.
This filter can be used toimplement GoalJobsSettings::set_from_repo_ids.
Within the dnf5 application, this filter will be utilized to filter
installed packages using the command-line option
"--installed-from-repo=".
We need to ensure repositories for requested packages are enabled.
During the enabling process, a check will also be performed to verify
that the requested repositories exist.
If our package installation request includes a restriction to only
repositories defined in `to_repo_ids`, we must retain only
the corresponding installed packages, and do so before checking
if the packages requested for installation are already installed.
This change ensures that `--from-repo` is applied only when specific
packages are provided on the command line.
I am preparing support for filtering from-repo in the DISTRO_SYNC_ALL,
UPGRADE_ALL, and UPGRADE_ALL_MINILMAL actions in libdnf5.
This adjustment in the dnf5 application ensures its behavior won't
change unexpectedly once the full support is added.
The actions UPGRADE_ALL, UPGRADE_ALL_MINIMAL, and DISTRO_SYNC_ALL
unnecessarily processed an empty queries, creating an empty IdQueue and
passing it to the functions `rpm_goal.add_upgrade` and
`rpm_goal.add_distro_sync`.
The actions UPGRADE_ALL, UPGRADE_ALL_MINIMAL, and DISTRO_SYNC_ALL
resolve package IDs directly (they do not call additional functions).
During resolution, the to_repo_ids setting was ignored. This fix ensures
that the setting is now taken into account.
Similar to autodetect_unsatisfied_installed_weak_dependencies (in
fact I stole the code from there). repoclosure can give bogus
failures for dependencies like (foo if bar). If nothing provides
foo in the repo(s) under test, but also bar is not present, that
should not be considered a repoclosure failure, but repoclosure
reports it as an "unresolved dep". See:
https://github.com/rpm-software-management/dnf-plugins-core/issues/549
Ideally we should handle rich dependencies correctly, but I cannot
see how to do that, so I'm sending this as an alternative that's
at least less-bad than the current state.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It was reported that selecting a package name from an output of "dnf5
search" command was difficult because of a colon adjacent to the
pacakge name:
$ dnf5 search dontpanic
Updating and loading repositories:
Repositories loaded.
Matched fields: name (exact)
dontpanic.i686: Very simple library and executable used in testing Alien::Base
Double-clicking on "dontpanic" word selected "dontpanic.i686:",
including the colon character. That made dificult to copy and paste
the found packages.
While this is a problem of the terminal emulator and later the reporter
found a setttings of his terminal not to do it, I think we should use
a pure white-space separator to help people with not so advanced
terminals.
This patch replaces the ": " separator with a single tabulation
character:
$ dnf5 search dontpanic
Updating and loading repositories:
Repositories loaded.
Matched fields: name (exact)
dontpanic.i686 Very simple library and executable used in testing Alien::Base
Resolves#2166
When we want distrosync to only use specified repositories for certain
packages, we shouldn't include their already installed versions. If
we did, distr-sync wouldn't perform the necessary downgrades to
the desired package versions, leaving the currently installed versions
in place instead.
The `--from-repo` argument allows the user to run distro-sync on
packages in the specified repositories. However, any dependency
resolution takes into account packages from all allowed repositories.
Multiple repository ids can be specified, separated by commas, and globs
can be used. Usage is similar to the `install` command.
The purpose is to enable multithread support in python. With the %thread
directive, the Python GIL is released before entering the methods from
repo_sack.hpp and acquired when exiting them. In case the methods are
called in a thread, another thread is not blocked by it. This is
especially important in case of loading repositories which can take
a lot of time.
The compiler decides when the variables are freed at the end of the function
and when the `user_data` is freed before the `downloader`, then the `downloader`
uses just freed `user_data` in the callbacks. The free order can be different
when the function is left due to an exception.
Fixes https://github.com/rpm-software-management/dnf5/issues/2015
We need to call server methods without blocking the current thread.
Otherwise, the dnf5daemon-client cannot handle signals reporting
progress of repository/package downloading and RPM transactions.
Unfortunately, the repository key import confirmation workflow also
depends on signal handling.
Curiously, blocking calls used to work with sdbus-cpp v1, but with v2
any signal handler was blocked until the call finished.
In my test system there is no D-Bus server running in systemd updates
environment. Therefore rebooting by calling a D-Bus method fails:
čen 30 13:17:52 fedora-43 dnf5[642]: Couldn't connect to D-Bus: [org.freedesktop.DBus.Error.FileNotFound] Failed to open bus (No such file or directory)
čen 30 13:17:52 fedora-43 systemd[1]: dnf5-offline-transaction.service: Main process exited, code=exited, status=1/FAILURE
čen 30 13:17:52 fedora-43 systemd[1]: dnf5-offline-transaction.service: Failed with result 'exit-code'.
čen 30 13:17:52 fedora-43 systemd[1]: Failed to start dnf5-offline-transaction.service - Offline upgrades/transactions using DNF 5.
I tried to exececute "shutdown -r now" command or "systemctl reboot"
command instead to avoid starting D-Bus and logind daemons. The
commands indeed initiated the reboot, but still complained on missing
D-Bus.
Let's swallow the bitter pill and accept that systemd requires D-Bus:
This patch adds a dependency on dbus.socket to
dnf5-offline-transaction.service.
(Neveretheless, sometimes systemd is persuaded that dnf5 program finished
with a failure:
čen 30 16:03:17 fedora-43 systemd-logind[647]: The system will reboot now!
[...]
čen 30 16:03:17 fedora-43 dnf5[637]: Complete!
[...]
čen 30 16:03:18 fedora-43 systemd[1]: dnf5-offline-transaction.service: Main process exited, code=exited, status=1/FAILURE
but that's a different issue #2327).
When rebooting machine on an off-line upgrade, the system could be
rebooted without unmouning file systems because
org.freedesktop.systemd1.Manager.Reboot() D-Bus call performs
an immediate reboot.
This patch fixes it by using org.freedesktop.login1.Manger interface
which performs graceful shutdown. That means stopping services and
unmounting file systems. The logind method also employs inhibition
locks preventing e.g. inadverternt reboot when another users are
logged in.
The true argument enables interactive authorization with polkit.
That's useless after applying the updates, but useful before applying
them when a user issues "dnf5 offline reboot".
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2350947
Since commit 9930310 the binding files include
`#include "bindings/libdnf5/exception.hpp"` when running swig to
generate docs we need to include a path from where it can be found.
Change permissions required for:
- clean cache
- clean or cancel offline transaction (only before the rpm transaction begins)
- set finish action after offline transaction (reboot or poweroff)
Currently the main user of these APIs is gnome software which can (if
the dnf5daemon-server-polkit package is installed) allow wheel group
users to install/upgrade packages from configured repositories without
being prompted for passwords. We need to set the same checks also for
offline transaction management APIs. Otherwise the user is allowed to
prepare an offline transaction, but is prompted for a password anyway
due to the `set_finish_action()` call that is executed after the
packages are downloaded and the offline transaction is prepared and
stored.
If "all_advisories" option is present, not only advisories for the
currently installed version of the upgraded package are returned, but
also advisories for all versions between the original and currently
installed versions.
This commit introduces a new overload of the
AdvisoryQuery::filter_packages method that accepts a vector of
libdnf5::rpm::Nevra objects. This allows filtering advisories based on
whether they contain at least one AdvisoryPackage that matches a
provided NEVRA, using a specified comparison operator.
The reason is to be able to get advisories related to the given
transaction from the history database. These transactions can contain
packages that are no longer available in repositories; thus, we need to
filter not by the IDs stored in PackageSet, but directly by NEVRA
objects.
Create a new D-Bus interface to retrieve information from the dnf5
transaction history. The new History interface currently supports only
one method: "recent_changes". This method retrieves information from the
history database about changes in the installed package set since the
specified point in time.
Evan Goode