libdnf icon indicating copy to clipboard operation
libdnf copied to clipboard

[dnf5] Feature request. Be able to get package using a repo hierarchy

Open claneys opened this issue 5 years ago • 0 comments

Hello,

The main idea here is to get a package from a repository rather than another without any care of its evr, only the name. In fact, the idea is to priorise repository not package the same way then the repository configuration keyword "priority" does when a package has identical nevra but applied only if the name match in several repositories.

I saw a PR in reaction of the bugzilla ticket talking about version pinning. But that's not fit totally the needs we have.

I also saw the issue #141 to include Vendor locking support which is something that almost fulfill the conditions but does not cover the case where the vendor provide several repositories with the same packages but different versions.

This makes you able to "compose" your distribution using repository "layers" with depending on their priority will provides packages. The drawback of that is when your repository doesn't include correct dependencies theses deps will be installed by another one but not compatible because of some reasons (wrong version doesn't providing the correct api). So repositories have to be as much consistent as possible, this could be a difficulty...

This feature is some kind of an advanced feature that if not used with care could damage your distribution but if used well, it lets you compose your distribution efficiently to make it fit better your needs.

Example: Imagine having several repositories, each one providing a kernel customized for some boards, the Fedora original one will always provide a generic kernel suitable for most use cases, but if you want to use a kernel coming from a third party repositories even not using the same major version than the Fedora one, you'll only need to set a priority on the third party repo and then kernel will come from it without specifying the NVR. This could be resolved by Version Lock plugin you'd said, but you have to change the plugin setting if you want to follow version evolution from the repository where if you can just priorise the repo then you know that the package coming from it will always be chosen first.

Another example: Several repositories providing a software and its core dependencies rebuilt for its needs. Then you also want to pin the repository to be able to install the software with its stack of dependencies. Problem would come if several software needs the same dependency but different version of it then there is a conflict. Module resolves that problem, but here we try another way using namespace and multiple rpm db. There would be X namespace, lets call it a node, with X rpm databases, each child node rely on its parents nodes to solv its dependencies. So RPM database are separated but linked together when solving dependencies is done.

There is an ongoing work here that's already work using that mechanic.

claneys avatar Jun 15 '20 12:06 claneys