Explicit Conflicts: in leaf packages

praiskup commented

2025-09-19 08:27:21 +00:00

Member

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?

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](https://docs.fedoraproject.org/en-US/packaging-guidelines/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?

praiskup commented

2025-09-19 08:32:22 +00:00

Author

Member

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.

tibbs commented

2025-09-22 01:21:48 +00:00

Owner

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.

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.

praiskup commented

2025-09-23 07:13:42 +00:00

Author

Member

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.

> 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.

praiskup commented

2025-09-23 07:15:28 +00:00

Author

Member

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.

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.