On Wed, Sep 27, 2017 at 8:25 AM, Panu Matilainen <pmatilai@xxxxxxxxxxxxxxx> wrote: > On 09/23/2017 12:12 PM, nicolas.mailhot@xxxxxxxxxxx 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! _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
