On Mon, Jun 15, 2020 at 7:49 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Mon, Jun 15, 2020 at 7:46 AM Richard W.M. Jones <rjones@xxxxxxxxxx> 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 ...
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
