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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
