On Mon, Jun 15, 2020 at 07:50:11AM -0400, Neal Gompa wrote:
On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones rjones@redhat.com wrote:
We autogenerate RPM Requires/Provides in a few projects, and it's quite nice. eg: supermin-devel has:
$ rpm -ql supermin-devel /usr/lib/rpm/fileattrs/supermin.attr /usr/lib/rpm/supermin-find-requires
and this means other packages that contain supermin appliances can simply put their appliance in a particular directory matching the name "*/supermin.d/packages/" and (since they have to BuildRequire supermin-devel anyway) RPM will create the correct dependencies automatically.
Great! But ...
I'd like to use it to autogenerate nbdkit plugin Provides, where the presence of a file named something like %{_libdir}/nbdkit/plugins/*.so should generate a Provides with the plugin name, eg:
$ rpm -qf --provides /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so nbdkit-curl-plugin = 1.21.7-1.fc33
Right now we list them explicitly:
https://src.fedoraproject.org/rpms/nbdkit/blob/master/f/nbdkit.spec#_161
The problem is all the current plugins exist in nbdkit itself. nbdkit is not a BuildRequire of nbdkit, so it cannot provide RPM rules for itself. Doing so would create a nasty circular dependency that makes bootstrapping awkward.
I could create a subpackage with the RPM rules, which is still a circular dependency but at least the subpackage would be noarch and wouldn't depend on anything else.
This is getting complicated - is there some easier thing I'm missing here?
I *think* you can include your own Provides generator script and just define the macros in the spec like you would in an attr file, and it should work.
Something like so:
%__nbdkitplugins_provides %{SOURCE11} %__nbdkitplugins_path ...
Blech, I mean:
%global __nbdkitplugins_provides ... %global __nbdkitplugins_path ...
Is there an actual example of this?
As far as I can tell this replaces the entire dependency generator, rather than enhancing it, but I'm probably wrong as the documentation is extremely oblique.
Rich.