[Rpm-maint] [rpm-software-management/rpm] RFC: rpmlib efi provides (#438)

[Florian Festi]

This concept of probes or dynamic provides or how ever they may be named are currently alien to rpm. To add them we need some more general solution than hard coding something for EFI. In general the rpm code should stay as much ignorant of the system it is used on as possible. So hard coding different boot systems can only be the very large resort of monumentally important problems.
There is something like this in libzypp (used by openSUSE) which injects system Provides into the transaction. Any solution for rpm needs to examine this first.
There are a few issues that have not come up here: 
Main use of such a mechanism will installing packages for hardware support based on the presence of said hardware. This will in most cases require pattern matching as addressing each hardware variant is not practical. IIRC libzypp does have some special idiom for this that uses RE or may be fnmatch patterns.
The next thing is that most package installations happen on an empty system. So any mechanism that relies too heavily on scripts/programs on the system is doomed to fail. Especially as the dependency resolution is done before anything gets installed. 

Something that is within the reach of getting into rpm would be some "exists(FNMATCH)" special name. That would look into the actual file system and not rely on the rpm database. But someone would still need to evaluate if this is feasible and actually solving the real world use cases  - especially during first installation.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/438#issuecomment-392513391
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180528/466da901/attachment.html>