Creating an autoprovides files

Hi,

I seem to remember that there was a way in recent rpm to declare autoprovides without touching the rpm package itself.

ie drop a file somewhere that tells rpm to process some path patterns with a script that outputs provides strings

However, I don't seem to manage to find the feature documentation (too many hits explaining how to disable automatic dependency generation). Can anyone on the list point me the right Fedora way?

Basically go packages really want to generate the "golang(foo)" autodep for every installed foo subdir of %{gopath}/src/ that contains some stuff.

Regards,

<DKIM> Creating an autoprovides files

And, replying to myself, the actual autoprovides should be

golang(foo) = %{version}-%{release}

Regards,

[Petr Pisar]

On Thu, Sep 21, 2017 at 05:51:27PM +0200, [e-mail] wrote:
> I seem to remember that there was a way in recent rpm to declare
> autoprovides without touching the rpm package itself.
>
> ie drop a file somewhere that tells rpm to process some path patterns with
> a script that outputs provides strings
>
> However, I don't seem to manage to find the feature documentation (too many
> hits explaining how to disable automatic dependency generation). Can anyone
> on the list point me the right Fedora way?

See perl-generators package:

$ rpm -ql perl-generators
/usr/lib/rpm/fileattrs/perl.attr
/usr/lib/rpm/fileattrs/perllib.attr
/usr/lib/rpm/perl.prov
/usr/lib/rpm/perl.req
/usr/share/doc/perl-generators
/usr/share/doc/perl-generators/Changes
/usr/share/doc/perl-generators/TODO

The /usr/lib/rpm/fileattrs/* files pairs a file path or file type criterion to
a script to run on the matched files. The scripts are /usr/lib/rpm/perl.*.
They get list of files names to scan on standard input and thei print the
dependency symbol on standard output.

-- Petr

De: "Petr Pisar"
> See perl-generators package:

Thanks a lot, I really needed this starting point

Regards,

[Neal Gompa]

On Thu, Sep 21, 2017 at 11:51 AM,   wrote:
> Hi,
>
> I seem to remember that there was a way in recent rpm to declare autoprovides without touching the rpm package itself.
>
> ie drop a file somewhere that tells rpm to process some path patterns with a script that outputs provides strings
>
> However, I don't seem to manage to find the feature documentation (too many hits explaining how to disable automatic dependency generation). Can anyone on the list point me the right Fedora way?
>
> Basically go packages really want to generate the "golang(foo)" autodep for every installed foo subdir of %{gopath}/src/ that contains some stuff.

openSUSE has some auto req/prov stuff for Go:
https://github.com/opensuse/golang-packaging

De: "Neal Gompa"
> openSUSE has some auto req/prov stuff for Go:
> https://github.com/opensuse/golang-packaging

Thanks for the pointer!
Unfortunately it seems to diverge in a big way from existing Fedora packages, and I don't really want to break compat (just make it easier to create/maintain new go packages)

But, I'll take a look if there are some ideas to steal, since it's GPLv3 like Fedora go macros

Regards,

[Panu Matilainen]

On 09/21/2017 06:51 PM, [e-mail] wrote:
> Hi,
>
> I seem to remember that there was a way in recent rpm to declare autoprovides without touching the rpm package itself.
>
> ie drop a file somewhere that tells rpm to process some path patterns with a script that outputs provides strings
>
> However, I don't seem to manage to find the feature documentation (too many hits explaining how to disable automatic dependency generation). Can anyone on the list point me the right Fedora way?
>
> Basically go packages really want to generate the "golang(foo)" autodep for every installed foo subdir of %{gopath}/src/ that contains some stuff.

See http://rpm.org/user_doc/dependency_generators.html

For practical examples see
https://github.com/rpm-software-management/rpm/tree/master/fileattrs 
and/or your local /usr/lib/rpm/fileattrs/ directory, eg. pkgconfig and 
desktop deps are purely path based.

- Panu -

<DKIM> Re: Creating an autoprovides files

De: "Panu Matilainen"
> See http://rpm.org/user_doc/dependency_generators.html

Panu,

Thanks for the pointer. I did know it must be documented somewhere :)

I have more questions

First, what is the exact point of %__NAME_provides_opts?
I had already used
%__go_provides %{_rpmconfigdir}/go.prov --root "%{buildroot}%{gopath}" --version "%{version}-%{release}"

and the argument passing seemed to work (in rawhide), or is there a special reason to use %__NAME_provides_opts instead? Will %__NAME_provides_opts appear as arguments or env variables?

Then, there is the question of the versionning

I can easily emit now provides such as
golang(gopackagename) = %{version}-%{release}

However go is heavily git-oriented and some of its "versions" do not automap to rpm.

What I'd actually like to emit is:
  — for proper monotonic versions
      golang(gopackagenameA) = %{version}-%{release}

— for special versions such as alphaB
      golang(gopackagenameA)(vermod=alphaB) = %{version}-%{release}

— For git commits
      golang(gopackagenameA)(commit=commitB) = %{version}-%{release} #master is implied
    or 
      golang(gopackagenameA)(commit=commitB)(branch=branchC) = %{version}-%{release}

And have a package that provides 
  golang(gopackagenameA)(commit=commitB)(branch=branchC)
resolve for any of
  golang(gopackagenameA)
  golang(gopackagenameA)(commit=commitB)
  golang(gopackagenameA)(branch=branchC)
  golang(gopackagenameA)(commit=commitB)(branch=branchC)
  golang(gopackagenameA)(branch=branchC)(commit=commitB)

And a package that provides
  golang(gopackagenameA)(vermod=alphaB)
resolve for any of
  golang(gopackagenameA)
  golang(gopackagenameA)(vermod=alphaB)

Is there a way to do this cleanly in rpm without emitting all the possible combinations in the autoprovider?
If there is no other possibility than emitting all the possible combinations, do the list have any syntax preference?

Regards,

<DKIM> Re: Creating an autoprovides files

[Panu Matilainen]

On 09/23/2017 12:12 PM, [e-mail] wrote:
> De: "Panu Matilainen"
> > See http://rpm.org/user_doc/dependency_generators.html
>
> Panu,
>
> Thanks for the pointer. I did know it must be documented somewhere :)
>
> I have more questions
>
> First, what is the exact point of %__NAME_provides_opts?
> I had already used
> %__go_provides %{_rpmconfigdir}/go.prov --root "%{buildroot}%{gopath}" --version "%{version}-%{release}"
>
> and the argument passing seemed to work (in rawhide), or is there a special reason to use %__NAME_provides_opts instead? Will %__NAME_provides_opts appear as arguments or env variables?

_opts is there so you can pass extra options from specs without having 
to override the entire command and it's not supposed to be used in any 
default setting. As it says in the docs actually:

---
The _opts macros should not be used in file attribute definitions, they 
are intended for spec-specific tweaks only. Note that any options are 
fully generator-specific, rpm only requires generators to support the 
stdin, stdout protocol.
---

And yes anything in _opts appears as cli arguments, but it's only 
intended for option arguments as the name implies.
> Then, there is the question of the versionning
>
> I can easily emit now provides such as
> golang(gopackagename) = %{version}-%{release}
>
> However go is heavily git-oriented and some of its "versions" do not automap to rpm.
>
> What I'd actually like to emit is:
>    — for proper monotonic versions
>        golang(gopackagenameA) = %{version}-%{release}
>
> — for special versions such as alphaB
>        golang(gopackagenameA)(vermod=alphaB) = %{version}-%{release}
>
> — For git commits
>        golang(gopackagenameA)(commit=commitB) = %{version}-%{release} #master is implied
>      or
>        golang(gopackagenameA)(commit=commitB)(branch=branchC) = %{version}-%{release}
>
> And have a package that provides
>    golang(gopackagenameA)(commit=commitB)(branch=branchC)
> resolve for any of
>    golang(gopackagenameA)
>    golang(gopackagenameA)(commit=commitB)
>    golang(gopackagenameA)(branch=branchC)
>    golang(gopackagenameA)(commit=commitB)(branch=branchC)
>    golang(gopackagenameA)(branch=branchC)(commit=commitB)
>
> And a package that provides
>    golang(gopackagenameA)(vermod=alphaB)
> resolve for any of
>    golang(gopackagenameA)
>    golang(gopackagenameA)(vermod=alphaB)
>
> Is there a way to do this cleanly in rpm without emitting all the possible combinations in the autoprovider?
> If there is no other possibility than emitting all the possible combinations, do the list have any syntax preference?

No comment there, except that rich dependencies [*] of course allow for 
all sorts of possibilities that haven't been possible before, but then 
they're not yet permitted in Fedora in requires (but it's not that far 
away either AFAICS). I seem to recall there was some language packaging 
specifically waiting for rich deps in requires to become feasible - 
might be golang, might be something else or just me dreaming...

[*] http://rpm.org/user_doc/boolean_dependencies.html but that's 
currently missing additions in 4.14

- Panu -

<DKIM> Re: Creating an autoprovides files

[Neal Gompa]

On Wed, Sep 27, 2017 at 8:25 AM, Panu Matilainen
 wrote:
> On 09/23/2017 12:12 PM, [e-mail] wrote:
> > De: "Panu Matilainen"
> > > See http://rpm.org/user_doc/dependency_generators.html
> >
> > Panu,
> >
> > Thanks for the pointer. I did know it must be documented somewhere :)
> >
> > I have more questions
> >
> > First, what is the exact point of %__NAME_provides_opts?
> > I had already used
> > %__go_provides %{_rpmconfigdir}/go.prov --root "%{buildroot}%{gopath}"
> > --version "%{version}-%{release}"
> >
> > and the argument passing seemed to work (in rawhide), or is there a
> > special reason to use %__NAME_provides_opts instead? Will
> > %__NAME_provides_opts appear as arguments or env variables?
>
> _opts is there so you can pass extra options from specs without having to
> override the entire command and it's not supposed to be used in any default
> setting. As it says in the docs actually:
>
> The _opts macros should not be used in file attribute definitions, they are
> intended for spec-specific tweaks only. Note that any options are fully
> generator-specific, rpm only requires generators to support the stdin,
> stdout protocol.
>
> And yes anything in _opts appears as cli arguments, but it's only intended
> for option arguments as the name implies.
> > Then, there is the question of the versionning
> >
> > I can easily emit now provides such as
> > golang(gopackagename) = %{version}-%{release}
> >
> > However go is heavily git-oriented and some of its "versions" do not
> > automap to rpm.
> >
> > What I'd actually like to emit is:
> >    — for proper monotonic versions
> >        golang(gopackagenameA) = %{version}-%{release}
> >
> > — for special versions such as alphaB
> >        golang(gopackagenameA)(vermod=alphaB) = %{version}-%{release}
> >
> > — For git commits
> >        golang(gopackagenameA)(commit=commitB) = %{version}-%{release}
> > #master is implied
> >      or
> >        golang(gopackagenameA)(commit=commitB)(branch=branchC) =
> > %{version}-%{release}
> >
> > And have a package that provides
> >    golang(gopackagenameA)(commit=commitB)(branch=branchC)
> > resolve for any of
> >    golang(gopackagenameA)
> >    golang(gopackagenameA)(commit=commitB)
> >    golang(gopackagenameA)(branch=branchC)
> >    golang(gopackagenameA)(commit=commitB)(branch=branchC)
> >    golang(gopackagenameA)(branch=branchC)(commit=commitB)
> >
> > And a package that provides
> >    golang(gopackagenameA)(vermod=alphaB)
> > resolve for any of
> >    golang(gopackagenameA)
> >    golang(gopackagenameA)(vermod=alphaB)
> >
> > Is there a way to do this cleanly in rpm without emitting all the possible
> > combinations in the autoprovider?
> > If there is no other possibility than emitting all the possible
> > combinations, do the list have any syntax preference?
>
> No comment there, except that rich dependencies [*] of course allow for all
> sorts of possibilities that haven't been possible before, but then they're
> not yet permitted in Fedora in requires (but it's not that far away either
> AFAICS). I seem to recall there was some language packaging specifically
> waiting for rich deps in requires to become feasible - might be golang,
> might be something else or just me dreaming...
>
> [*] http://rpm.org/user_doc/boolean_dependencies.html but that's currently
> missing additions in 4.14

Unless we're both dreaming.. :)

But yeah, Rust needs the new functionality.