On Wed, Sep 27, 2017 at 8:25 AM, Panu Matilainen
<pmatilai(a)laiskiainen.org> wrote:
On 09/23/2017 12:12 PM, nicolas.mailhot(a)laposte.net 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.
--
真実はいつも一つ!/ Always, there's only one truth!