madonuko left a comment (rpm-software-management/rpm#3691)
> If you now add more (typically conflicting) Requires(pre)'s into the picture,
> you have just taken away rpm's last chance of figuring a non-destructive way
> to resolve a dependency loop.
That's the way I reproed this issue; the originally issue did not involve any
`Requires(pre):` in the problematic package `ultramarine-release-plasma`; in
fact, it does not have any direct dependencies other than
`ultramarine-release-common` and `ultramarine-release-desktop`, and they
install fine both together and separately. However,
`ultramarine-release-plasma` triggered this issue regardless of
`install_weak_dependencies`.
```
$ dnf rq --provides ultramarine-release-plasma --releasever=42
--repo=ultramarine
Updating and loading repositories:
Repositories loaded.
base-module(platform:f42)
system-release
system-release(42)
system-release-product
ultramarine-release = 42-2.um42
ultramarine-release-kde = 42-2.um42
ultramarine-release-plasma = 42-2.um42
ultramarine-release-variant = 42-2.um42
```
If one of the packages in the dependency chain depends on one of the above
entries, then obviously it would create a cyclic dep chain.
```
$ dnf rq --provides fedora-release-kde --releasever=42 --repo=fedora
Updating and loading repositories:
Repositories loaded.
fedora-release = 42-0.22
fedora-release-kde = 42-0.22
fedora-release-variant = 42-0.22
system-release
system-release(42)
```
Using `dnf rq` I checked that nothing in the Fedora repos satisfy
`--whatrequires` `system-release-product` or `base-module(platform:f42)`.
So under these circumstances the intended behaviour of dnf / rpm is to
obviously replicate what it does with `fedora-release-kde` and install `glibc`
first before running the scriptlets; however that's unfortunately not the
behaviour we see, so there's something indeterministic and something wrong with
the depsolver / rpm. And that's how I discovered this issue and wrote this
repro (so you don't have to deal with extra repos). (For clarity, given the
same deps, when they are cyclic, dnf doesn't generate the same sequence of
packages to install, which is the concerning part.)
[The spec file for `ultramarine-release` is
here](https://github.com/Ultramarine-Linux/packages/blob/b8580535772e546817bfbeeb5e29bcad0ae344e6/ultramarine/release/ultramarine-release.spec#L946-L952).
The lines highlighted are the `%preun` and `%post` scripts for the
`ultramarine-release-identity-plasma` package, which satisfies a `Requires:` in
`ultramarine-release-common`. It takes a while to search but as you can see
`ultramarine-release-plasma` itself has no scriptlets and thus it's safe to
assume there are no `Requires(pre):`s.
Therefore I believe there is virtually no reason why
`ultramarine-release-plasma` should have a different depsolv result compared to
`fedora-release-kde`.
In case you want to test the ultramarine packages: `--repofrompath
'ultramarine,https://repos.fyralabs.com/um42' --nogpgcheck`
Logs:
[dnf4](https://github.com/Ultramarine-Linux/images/actions/runs/14074642779/job/39415343794#step:6:5446)
[dnf5](https://github.com/Ultramarine-Linux/images/actions/runs/14074642779/job/39415343869#step:6:4280)
So,
Problem 1: given virtually the same environment, why is `glibc` installed later?
Problem 2: why doesn't rpm know it should install `glibc` first with cyclic
deps?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3691#issuecomment-2772015104
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3691/2772015...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
