The issue was originally reported on DNF5.
The problem is that upgrade of `B-1-1.i686` result in RPM in removal of
`B-2-2.x86_64` and `B-1-1.x86_64`.
The issue is reproducible from commandline, API (Python DNF, C DNF5). The
behavior caused for DNF4 complains in callbacks, but DNF5 correctly fa
I used two packages from our CI -
https://github.com/rpm-software-management/ci-dnf-stack/tree/main/dnf-behave-tests/fixtures/specs/security-upgrade-multilib
```
Name: B
Epoch: 0
Version:1
Release:1
License:Public Domain
URL:None
Summary:
I believe that the issue could be reproduced with standard RPMs because in the
original report the problem was triggered with `glibc`
```
# rpm -q glibc
glibc-2.37-1.fc38.x86_64
glibc-2.37-1.fc38.i686
glibc-2.37-4.fc38.x86_64
```
--
Reply to this email directly or view it on GitHub:
https://gi
Be honest from API and DNF side we would love to see that RPM will not modify
transaction request, but only check whether it is applicable.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1891721497
You are receiving t
I just want to point out that structure might be vie reversa. Instead
```
- arch: aarch64
repos:
repoid:
packages:
```
To use
packages:
wget:
repoid:
baseos
arch:
x86_64
s390
```
Then I discovered one problem when o
It will unify interface with other function like ts.addReinstall(hdr, data). It
also will help to DNF to pair RPM transaction item with DNF DB item.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1825162
--
You are receiving this because you are subscribed to this thread.
Reply to this e
The behaviour is inconsistent with commandline behaviour when removal of
removed package returns an error. Ignoring of erase step makes inconsistency
between rpm transaction and transaction in DNF.
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1815327
```
$rpm -q acpi
package acpi is not
In dnf-4 it is clear. We create for each operation a separate transaction item.
Upgrade is not a single operation but operation of upgrade and upgraded. See
dnf/db/group.py:_populate_rpm_ts().
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or v
Please could you look at dnf/db/group.py:_populate_rpm_ts()? There you will see
that for each element in swdb we created a single rpm transaction element. The
problem is when transaction elements do not match after transaction.
When I created any transaction element in rpm (ts.addErase(tsi.pkg.id
But the same issue is with a single remove step. Try:
dnf install acpi -y
dnf remove acpi # wait till rpm -e acpi is performed in another terminal, then
approve it.
At the time of creation of remove operation for rpm
('dnf/db/group.py:_populate_rpm_ts()') the package i already gone, but rpm do
@pmatilai Please could you fix it as soon as possible?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1213#issuecomment-631989602_
> So rpm would need to invent something, but how does the callee then know how
> to locate that when it was rpm that invented it
@pmatilai Thank you for any changes. Please keep in mind that it was originally
requested in bugzilla, and we would like to use it in next RHEL.
> You need to start w
It is difficult to decide which package from a repository was installed,
because repodata created by createrepo contains only checksum of the whole
package and rpmdb contains only checksum of a header. What about to store such
an information in RPMDB?
--
You are receiving this because you are
RPM and DNF have several differences in CLI and API. In long term it will be
nice to improve consistency between similar or related components. As an
example I can use handling of epoch. See `rpm -q dnf` and `dnf repoquery dnf`.
Also the output for `--queryformat="%{epoch}"` differs. DNF shows `
Yes I know. And it would be a braking change to change anything related to
scriptlets. But as I saw RPM is creating a plan for RPM6 and DNF team is
working on DNF5 therefore we have a room for the changes. I think that we need
to do something for inexperienced users with a broken system. Therefo
I know that this is not exactly about RPM6 format but it is related to a new
major version of RPM.
There are few things in our environment that are painful for our users but it
is not easy to resolve them:
- broken systems
- There are multiple ways how to get to that state and sometimes we ha
What about inconsistency between repo metadata and in RPMDB with package
checksums. Metadata contains file checksum (only one type), but RPMDB contains
a header checksum (multiple types). We have some users who wants to align
available packages with installed one and there is not enough informa
Is there any planned change related to changelogs?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5613128
You are receiving this because you are subscribed to this thread.
Message ID:
__
Thank you for moving it to a proper place
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5613138
You are receiving this because you are subscribed to this thread.
Message ID:
___
If I am not mistaken - changelogs are stored in rpm header and they are
uncompressed. Is there any reason to have them uncompressed?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5617027
You are receiving t
In librepo we prepare implementation without GPGme
(https://github.com/rpm-software-management/librepo/pull/275). I would prefer
to require rpm with rpm-sequoia back-end when librepo will use RPM instead of
GPGME. It will ensure that we will use the tested backend and if someone will
need to r
In dnf5 source has `BuildRequires: pkgconfig(rpm) >= 4.17.0`
Then the library (libdnf5) requires `librpm.so.9()(64bit)`
In theory if rpm-libs will provide `rpm-libs(sequoia)` then we can use
something like
`Requires: ( rpm-libs{?_isa} >= %{rpm_version} with `rpm-libs(sequoia) )`
If rpm-devel w
My apology. I see other options. In past we faced a problem with librepo and
zchunk where library was build without zchunk support (RHEL) but libdnf with
support (copr). We resolved it by `#define LRO_SUPPORTS_CACHEDIR` in librepo.
Then libdnf was able to detect whether librepo supports it or no
https://bugzilla.redhat.com/show_bug.cgi?id=1666835
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/645
-- Commit Summary --
* Add support for arch "aarch64:m3ulcb"
-- File Changes --
M rpmrc.in (9)
-- Patch Links --
24 matches
Mail list logo
