We would like to switch to exclusively using Packit for building and
testing pull requests, so we are retiring this GitHub Action workflow.
We will want to configure Packit to check that DNF5 compiles with both
GCC and clang, like the Package Build action did.
In order to fully disable the action, this commit must be applied on
each branch in the upstream DNF5 repository. Otherwise, the action might
be triggered by a pull request to some stale branch.
The code works on rpm level anyway and I'd like to use this mechanism in
transaction callback to present the outputs to the user.
Also adds rpm::Transaction class member to store the output of the last
scriptlet.
Currently, the path where a package should be downloaded is computed in
several places. This patch introduces a single location for this
computation to reduce code duplication.
The patch also fixes usage of incorrect package path in
Package::get_package_path() call - the destdir config option was not
taken into account.
First not every system has user's home directories under /home
directory. Second DNF does not use USER variable at all. It uses HOME
environment variable with a fallback to a home directory listed in
passwd(5) entry.
Alternativelly, we could write "$HOME". But I find "~" shorter, more
aesthetic, more understandible, and more correct in case the HOME
variable does not exist.
Actually use the system's installation time (if known) as the reference
point, instead of the first-ever countme event recorded for the given
repo.
This is what the dnf5.conf(5) man page always said about the countme
option, the code just never lived up to that.
This makes bucket calculation more accurate:
1. System upgrades will no longer reset the bucket to 1 (this used to be
the case due to a new persistdir being created whenever $releasever
changed).
2. Systems that only reach out to the repos after an initial time period
after being installed will no longer appear younger than they really
are.
3. Prebuilt OS images that happen to include countme cookies created at
build time will no longer cause all the instances spawned from those
images (physical machines, VMs or containers) to appear older than
they really are.
Use the machine-id(5) file's mtime to infer the installation time. This
file is semantically tied to the system's lifetime since it's typically
populated at installation time or during the first boot by an installer
tool or init system, respectively, and remains unchanged.
The fact that it's a well-defined file with clear semantics ensures that
OS images won't accidentally include a prepopulated version of this file
with a timestamp corresponding to the image build, unlike our own cookie
files (see point 3 above).
In some cases, such as in OCI containers without an init system running,
the machine-id file may be missing or empty, even though the system is
still used long-term. To cover those, keep the original, relative epoch
as a fallback method. System upgrades aren't really a thing for such
systems so the above point 1 doesn't apply here.
Some containers, such as those created by toolbox(1), may also choose to
bind-mount the host's machine-id file, thus falling into the same bucket
as their host. Conveniently, that's what we want, since the purpose of
such containers is to blend with the host as much as possible.
Backport from dnf4: cc95edd15b
The buckets aren't really an array that's indexed in the code, they're
just sequential numbers for the URL flag. Also clarify why we're using
"this window" instead of "the current position of the sliding window" in
the comments.
Backport from dnf4: cc95edd15b
This is a new flag in the recent 0.7.30 release.
It is used only in current rawhide.
We previously tried to use `SOLVER_FLAG_FOCUS_BEST` but it turned out to
be too strong, this new flag should update packages only if it is
required for installing the latests versions of dependencies.
We had several reports where users expect this behavior.
This should properly resolve issue such as:
https://bugzilla.redhat.com/show_bug.cgi?id=2150300https://issues.redhat.com/browse/RHEL-1374
This adds the same options used by rpmbuild, mock, etc. for setting
macros to flip build-time conditional switches when parsing spec
files. It provides a consistent interface across related tools.
If the scriptlet finishes successfully, do not print the
"Running scriptlet..." / "Stop scriptlet..." pair of messages in the
transaction progress bar.
The "Running scriptlet" message is displayed during the scriptlet
execution to inform the user that a time-consuming operation is in
progress. If the scriptlet completes successfully, the message is
removed. If it fails, the message remains, and an error/warning message
and the "Stop scriptlet" message is printed to enable debugging.
ELF plugins of dnf5-plugins and dnf5-plugin-automatic subpackages link
to libdnf and libdnf-cli libraries. Because the libraries come from
the same source package, it is desired to pin the plugin subpackages
to same release of the libraries subpackages.
This was hinted by rpminspect and already partially implemented in
commit 97cdbe57c3 ("Add explicit package
version for libdnf5-cli").
Implements `clean()` method on `Base` interface to clean requested types
of caches. Supported types are "all", "packages", "metadata", "dbcache",
and also "expire-cache" for marking repository metadata expired.
This makes a difference if `--ignore-installed` is set and the package
is installed in a different version -> it upgrades/downgrades the
package to the requested version.
This matches dnf4 behavior.
If a package is already installed in the requested version but with a different reason override the reason.
This is useful when redoing an interrupted transaction.
The longest part of a transaction is running rpm changes, saving reasons is done after rpm finishes. If a transaction
is interrupted in the middle of the rpm part some rpms are changed but reasons are not updated at all. To handle this
enforce the reasons in the selected transaction.
By default the transaction during the `download()` call does not copy
local packages to the destination directory. These packages are used
directly from their original location. For some use-cases (like offline
transaction involving the command line repo packages) we need to copy
them to the package cache.
Evan Goode