> One possible disadvantage: you wouldn't be able to e.g. dnf downgrade xz*
I think it's important to differentiate the real binary dependencies from RPM's
knowledge of those dependencies.
In Fedora 40, it was safe to downgrade xz because libsystemd had been built
before xz 5.6. If it had been built after, that might not have been true.
xz 5.6 introduced at least one new symbol: `lzma_mt_block_size`. It's not
certain that libsystemd would have had a reference to this symbol if it had
been built in a build root with xz 5.6, but it could have. And if it did, then
reverting to xz-5.4 would have caused everything linked to libsystemd to fail
to start. Fedora's maintainers would surely have noticed that, and would have
rebuild systemd in a build root with xz-5.4, and pushed that update along with
the xz-5.4 downgrade, but hypothetically, users might have decided that only xz
was worth updating. If they'd updated only the revert-to-5.4 xz packages, the
result would have been a disaster on those systems.
But as you point out, if this change was already deployed, then downgrading xz
would also downgrade everything that was built against xz-5.6, which would have
avoided any users mistakenly breaking everything linked to a hypothetical
libsystemd that required symbols in 5.6.
So as I see it, the xz downgrade is a really good illustration of why this
change is needed. We were lucky that we were able to safely downgrade that
package. We should not rely on luck.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2035519467
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2372/c2035519...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
