The problem with probes (like your patch) is that RPM is attempting to run a
dependency assertion checker whose values are known at the end of an
installation, not at the beginning, by also checking added packages.
Since a /sys path is dependent on both a kernel capability as well as the mount
being performed, and there are no details contained in added package metadata
to help resolve the probe dependency, there likely would need to be disablers
on the probe namespace when rpmtsCheck() is called to permit, say, the
transition from a non-uefi -> a uefi based system that contained a probe
dependency.
I personally do not think that the inability to resolve a probe dependency
against added packages or depsolver metadata as the sine qua non, but YMMV. The
point has been brought up in the past however.
--
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-385044068
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
