Re: Easier way to autogenerate Provides?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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 ...

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux