i586 <-> i686 is exactly the same class as i586 <-> i686 when the color is zero
for one of the rpms.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1896129493
You are receiving this because you are subscribed to this
Right, that one. An architecture change is a fairly special operation, I'm not
convinced it needs to "just work" with regular update, it just needs to be
doable. Eg, using --replacepkgs, which back then it wasn't. Also, an i686
package *can* be considered an update to an i586 package, but a
An example would be: https://bugzilla.redhat.com/show_bug.cgi?id=966715
Don't you think an architecture change from i585 to i686 should delete the i586
package even if the NEVR is the same?
--
Reply to this email directly or view it on GitHub:
> What's so special about an identical NEVR? The content may still be
> different, we had a couple of bug reports about same NEVR with different
> files and rpm not doing the correct thing.
Because by the very definition of rpm, release must change any time content
changes?
That people
Regarding the original report: I'm not sure it is related to this issue. dnf5
should be able to replace multiple versions of an installed package. I'm not
sure the original problem is a multilib issue.
--
Reply to this email directly or view it on GitHub:
What's so special about an identical NEVR? The content may still be different,
we had a couple of bug reports about same NEVR with different files and rpm not
doing the correct thing.
--
Reply to this email directly or view it on GitHub:
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
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:
No colors are involved in this case (no files, but yes rpmteColorDS() is the
key to the coloring thing. It's weird alright.
I guess I thought thought the patch only affected --replacepkgs behavior when
that's what the commit message talks about and that's the testcase that chances
as well. But
Do we really want to do something special for "same NEVR"? I find that a bit
weird.
(But all that color handling is also super weird to me, and dnf/zypper also
does not know the package colors when calculating the transaction and has to
hope that the architecture matches the color.)
(BTW, is
AFAIR if the packages contain no files, they wont get any color.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1889371001
You are receiving this because you are subscribed to this thread.
Message ID:
Bisecting points the regression to commit
21836bc7524f8fc07972e0e56eed1c3b68775368
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-110637
You are receiving this because you are subscribed to this thread.
Message
Easily reproduced with that. This is not just a bug but a regression too, 4.14
doesn't behave this way.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1888743606
You are receiving this because you are subscribed to
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:
Rpm erasing the older versions is more or less expected (see below), but that
the equal version too seems bizarre and buggy alright. Can you provide the
reproducer for B, as simple as it may be?
For the erasure of older versions, the behavior depends on the package colors,
not architecture,
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
16 matches
Mail list logo
