packaging-committee

#1488 Explicit Conflicts: in leaf packages
Opened by praiskup. Modified

Open
Close Issue

There appear to be postgresql18-server, postgresql17-server, and postgresql16-server packages (and possibly others) in today’s Fedora 43. These packages are not parallel-installable. That said, having postgresql16-server available is admittedly very useful as a “compat” package in F43, since users upgrading from F42 can continue using PostgreSQL 16 without a data directory upgrade.

The Conflicts page touches on this topic:

It is acceptable to use Conflicts: in some cases involving compat packages. These are the cases where it is not feasible to patch applications to look in alternate locations for the -compat files, so the foo-devel and foo-compat-devel packages need to Conflict:. Whenever possible, this should be avoided.

However, at least postgresql17-server is not a true compat package (it's just a leaf alternative). Could we document this practice of providing “alternatives” as acceptable (with Conflicts:)?

Also, should we document somewhere the recommended way for users to switch between such package versions?

I've moved this to the correct tracker (from fesco/3474, sorry for the noise) and found a related issue, #1304, although it does not discuss parallel (non)instability.

I think in general we have moved away from the concept of "compat" packages in favor of just using properly versioned packages, but we haven't considered all of the places where the concept of "compat" packages was referenced.

The basic question is simply should the various different multiple versions be allowed to conflict with each other, and I think on some level that has to be allowed. I think we should certainly encourage it and I think with enough work it should be possible to do it in many cases, but not in all. And there's a question of how much work we should expect packagers to do here.

Documenting how users would switch between such packages would be quite out of the scope of the packaging guidelines, because they are definitely not where users would go to find such information.

Documenting how users would switch between such packages would be quite out of the scope

The problem is that a standard command like dnf install compatpkg20 fails. This makes the package appear broken, which would lead a typical user to file a bug report. If we are going to allow this pattern, there should be a supported way to install/reinstall these packages. The goal is to encourage higher package quality and to clearly define what is a bug and what is not.

For instance, I was encouraged to run dnf install compat --allowerasing, which seems much more dangerous than dnf swap. I would say that if dnf swap fails, it's a bug (and if maintainers provide these leaf packages, they should provide an easy way to swap those). However, my perspective might be too pedantic.

Note also the exception wording for new packages that do not require review https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#_package_review_exceptions

The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the naming guidelines and MUST NOT conflict with all other versions of the same package.

This probably needs change.

My understanding is that such packages with conflicts would still need a review, so the conflicts could be reviewed.
Metadata
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.