How to obsolete package once their dependencies are not satisfied?

[voxik]

Lets have some package installed on a system, which is already removed from the repository. This package might work just fine as long as their dependencies are satisfied. But after the dependencies change, the package needs to be removed. Is there a way to obsolete package under such condition?

The specific example could be this:

Problem 3: package rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires libruby.so.3.2()(64bit), but none of the providers can be installed
  - ruby-libs-3.2.2-181.fc39.x86_64 from @System  does not belong to a distupgrade repository
  - problem with installed package rubygem-byebug-11.1.3-5.fc39.x86_64

As long as the libruby.so.3.2()(64bit) is available, the rubygem-byebug-11.1.3-5.fc39.x86_64 package works fine. But is there a way to remove it from a system once the libruby.so.3.2()(64bit) is not available anymore?

This ticket is the background for my question.

[dmnks]

One way, I think, is to introduce a special distro-wide obsoleter package. Example from Fedora: https://src.fedoraproject.org/rpms/fedora-obsolete-packages. This assumes that the maintainers of the retired packages update this obsoleter package manually, though.

[voxik]

Yes, the package is precondition. But the question is if the Obsolete can be more nuanced.

[dmnks]

Oh, just noticed the linked ticket above is actually from the fedora-obsolete-packages repo 🤦

[dmnks]

Lets have some package installed on a system, which is already removed from the repository. This package might work just fine as long as their dependencies are satisfied. But after the dependencies change, the package needs to be removed.

A package installed on the system has its dependencies satisfied, by definition. The only way to change its dependencies is to run an rpm transaction. Such a transaction will fail if it can't satisfy the dependencies of an already installed package.

As long as the libruby.so.3.2()(64bit) is available, the rubygem-byebug-11.1.3-5.fc39.x86_64 package works fine. But is there a way to remove it from a system once the libruby.so.3.2()(64bit) is not available anymore?

Assuming "not available" as in "not available in the repositories", this question is then irrelevant to rpm as it doesn't deal with repositories and so can't know that.

If "not available" in the current rpm transaction, then that transaction will simply fail due to libruby.so.3.2()(64bit) not being satisfied.

[dmnks]

I think your question therefore belongs to the DNF layer. In fact, --allowerasing might just be what you're after.

[dmnks]

What rpm could help with is to e.g. optionally remove a package whose dependencies can't be satisfied in a given transaction. Basically, an analogy to --allowerasing in DNF. However, I'm not sure if that's really what rpm wants to support...

[dmnks]

This would probably also clash with DNF's own depsolving logic (libsolv).

[voxik]

What the fedora-obsolete-packages can do is to remove such package immediately. But that is not strictly needed. It is needed only when the ABI is broken.

I would like to have something like:

Obsoletes: rubygem-byebug unless libruby.so.3.2()(64bit)

or:

Obsoletes: rubygem-byebug if its-dependencies-can't-be-satisfied-anymore

Something like "soft obsolete", which would keep the package around as long as it is not objectively broken, no matter what is in repository (because repository is not the thing for RPM).

[hroncok]

I've said it before and I will repeated it here. Dnf should gain an option to allow erasing packages iff they are no longer available in the repos. Dnf system upgarde should default to this option (at least for Fedora-provided repos).

That way, we can stop manually tracking each retired package in artificial fedora-obsoletes-packages and we would not have to invent a way to "soft obsolete" packages. They would be automatically erased when they are removed from the distro AND no longer installable due to missing deps.

[dmnks]

Whether there's a reasonable replacement for the removed packages is another thing, a "social" one I suppose. That is, ideally there always are such replacements (Obsolete-ing the removed packages) and if there aren't, that should somehow perhaps be communicated in the Release notes or similar.

[dmnks]

Looking at Fedora's system upgrade guide, there's this:

If some of your packages have unsatisfied dependencies, the upgrade will refuse to continue until you run it again with an extra --allowerasing option.

That's basically what we've discussed so far, it's just not the default. Letting the user be in control of which of the two outcomes will happen actually seems quite reasonable.

Of course, it also presents a UI challenge - using the command-line way of upgrading may assume a certain level of knowledge (of how to fix such problems), however using e.g. GNOME Software certainly should show some kind of user-friendly prompt if there's such a conflict (that could only be resolved by removing the offending package).

[dmnks]

Argh, I've got a little tangled up here. What was discussed here was another (currently non-existing) option similar to --allowerasing but for packages that have no obsoleting package in the repos... Nevermind my last comment then.

[pmatilai]

Yeah this is something for the depsolve layer, rpm has no concept of repos and cannot know what packages are available.

On the depsolve layer this becomes a somewhat different problem: is the package really gone, or is it just temporarily unavailable due to out of sync mirrors or another repo issue? So probably not on by default, but system-upgrade should have it enabled.

[mlschroe]

The default in libsolv (and also what SUSE uses) is actually to remove those packages in distro-sync mode if they get in the way. But dnf turns disables this feature:

    /* don't erase packages that are no longer in repo during distupgrade */
    solver.set_flag(SOLVER_FLAG_KEEP_ORPHANS, 1);

This would be much better than --allowerasing, which basically tells libsolv to erase any package if there are dependency problems.

I think dnf should get an option to allow orphan erasing.

[voxik]

We agree that at some point, it is good idea to forcefully remove some package from a system. We know how to remove the package from the system, when it is removed from repository using e.g. fedora-obsolete-packages. The method could certainly be improved, but it works. But the assertion was:

"So since Fedora wants to preserve installed packages on system upgrade, even if they are not available in the new release, straight obsoleting is not the correct action. And if a package needs to be obsoleted is not necessarily known at orphaning or retirement time."

I see two options to help with this situation.

1. Improve metadata in RPM, because we can predict that if package not being maintained anymore, depending e.g. on libruby.so.3.2()(64bit) should be removed as soon and such provide is not available.
2. Improve process to collect appropriate metadata in fedora-obsolete-packages. Currently the process is "Lets ask users on ML for upgrade problems". We could possibly do better.

In any case, the purpose of this discussion is to focus on (1), i.e. is there something what RPM could do to help remove broken packages at the right moment? Because it is simply not surprise that e.g. libruby.so.3.2()(64bit) won't be available one day.