I am closing this PR as the proposed code is clearly not going in. Further
discussion can be done in the newly created #446
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #438.
--
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#event-1660932368___
Rpm-maint mailing list
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
There is (perhaps) a way to use the context of the dependency assertion
resolution to choose between two means of dependency resolution:
1) a namespace encapsulated virtual provide (think: Provides: system(EFI) in
some package)
2) a Boolean valued dependency probe function (think: your
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
See the cpuinfo() (which parses /proc/cpuinfo) or the sysconf() (which can
detect whether NPTL is used) namespaces as example probes in RPM5.
There is also a class of probes implemented as RWX() letter combinations as a
thin wrapper onto access(2) calls on a path that would work for
You are asking about how file dependencies work? The requirement I suggested
would be matched by an explicit Provides:, (not a path), in a kernel package
that is capable of uefi?
That "works" (in the sense that it is all that RPM4 has ever done, matching R
<-> P assertions contained in
How will that work? Is there some mechanism I haven't seen that makes kernel
filesystems work as file provides?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This makes it possible for a package to do:
Requires: system(EFI)
or
Conflicts: system(EFI)
I'm certainly open to other ways to do this, or other ways it needs to be
phrased.
You can view, comment on, or merge this pull request online at:
