Boolean (rich) Obsoletes

[mikhailnov]

I wanted to make a boolean Obsoletes:

Obsoletes: (firefox-esr52 if %{name})

but it is not allowed:

ошибка: строка 8: No rich dependencies allowed for this type: Obsoletes:	(firefox-esr52 if task-firefox_esr)

I understand why Provides cannot be boolean, but do not see reasons why package %name cannot Obsolete firefox-esr52 only if %name is installed and do not obsolete it if it is not.

[mikhailnov]

The actual problem that I am trying to solve is the following.

There multiple versions of firefox available in the repository: firefox-esr52, firefox-esr78.

We package ESR versions of Firefox and Thunderbird for users who reply on some extensions which are often broken by new major versions.

We want to ship ESR Firefox and/or Thunderbird in the distro ISO, but we do not want to keep old ESR installed after it becomes EOLed.

So, the idea was to make a package task-thunderbird which would depend from thunderbird-78, later from thunderbird-83 etc.
The problem is that conflicts between deiiferent versions of thunderbird prevents dnf from installing task-thunderbird despite the old version of thunderbird becoming orphaned.

[ffesti]

Obsoletes do look like dependencies but they are a different thing. They do alter the update path of a package basically saying "This package changed name and the line of updates continues here". As such they are matched against package names only and not against provides (as the new package may often have the same provides and may even provide the previous package name).
When introducing boolean dependencies we opted against adding boolean Obsoletes as Obsoletes are already complicated enough. Why not add the Obsolete to the firefox-esr78 packages as soon as firefox-esr52 is outdated (no longer supported).

[mikhailnov]

Thanks for explaining!

Why not add the Obsolete to the firefox-esr78 packages as soon as firefox-esr52 is outdated (no longer supported)

That can be done, but may break extensions and established workflows

[ffesti]

task-thunderbird should just have an Obsolete to the outdated version and require the new one. It does not need to be required as obsoleting packages get installed automatically as soon as the obsolete matches.

Anyway, we are not implementing rich Obsoletes any time soon. But I will keep you use case in the back of my head.