Support Vendor-locking about libdnf HOT 7 CLOSED

I would suggest supporting them as configuration files, so that repo release packages could install vendor classes to map related vendors together.

However, if this use-case isn't considered important, then going with a way to configure it at build time is fine.

Though I'd figure this would be a choice made at the package manager tool level, rather than the libhif level?

from libdnf.

Hmm...my intuition here is that the locking should be based on the origin repo (id). The RPM Vendor field isn't something users ordinarily interact with or see much (IME), but everyone knows about yum repos.

Worth noting rpm-ostree won't have the problem linked in the original bug because layered packages can't replace parts of the base system.

Also we should note the real problem is that whatever is generating those RPMs needs to also generate provides filters.

from libdnf.

@cgwalters Well, I think that's how libzypp implements it too.

That said, could a locking mechanism use multiple factors to judge a "vendor". Typically, you have GPG keys, the Vendor tag, and the repo ID from the *.repo file.

I would hazard a guess to say that the combination of these things could be used to constitute a vendor "class"?

from libdnf.

Also, another reason not to use the Vendor field is it's then something we're relying on the RPM authors to get right, but if they have other serious problems like not filtering provides...

Whereas .repo files are:

• Under client side control (modulo RPMs which include them but that's another topic...)
• Simple and harder to screw up

from libdnf.

I believe that Modularity provides an alternative. Please if you feel that the issue is still relevat, please open the bugzilla with detailed description of user-cases that the request will solve.

from libdnf.

Modularity definitely is not an alternative

from libdnf.

Closing this as dnf can now handle vendor locking
rpm-software-management/dnf#1602
#907

from libdnf.