[Rpm-maint] [rpm] #866: %include macros.foo

Panu Matilainen pmatilai at laiskiainen.org
Tue Feb 4 17:14:34 UTC 2014


On 02/04/2014 05:42 PM, Vít Ondruch wrote:
> Dne 28.1.2014 08:12, Vít Ondruch napsal(a):
>>
>>
>> #866: %include macros.foo
>> ----------------------+-----------------------------------------------------
>>
>>    Reporter:  vo.x     |       Owner:  RpmTickets
>>        Type:  defect   |      Status:  closed
>>    Priority:  major    |   Milestone:
>>   Component:  rpm      |     Version:  RPM Development
>> Resolution:  invalid  |    Keywords:
>> ----------------------+-----------------------------------------------------
>>
>> Changes (by pmatilai):
>>
>>    * status:  new => closed
>>    * resolution:  => invalid
>>
>> Comment:
>>
>>   Replying to [ticket:866 vo.x]:
>>   > If the package provides macros.foo rpm macros, it would be cool if I
>>   could include these macros into the .spec file for internal use. For
>>   example, in macros.ruby, we have defined constants, which are needed for
>>   configuration of Ruby package itself and later, they are shipped in
>> ruby-
>>   devel for build of other packages, which depends on Ruby.
>>   >
>>   > The regular %include macro can be used just inside of other blocks,
>> such
>>   as %prep, %build, etc,
>>
>>   Um, no. %include works anywhere in a spec.
>>
>>    so I have come up with following snippet:
>>   >
>>   > {{{
>>   > Source4: macros.ruby
>>   >
>>   > %{lua:
>>   >
>>   > for line in io.lines(rpm.expand("%{SOURCE4}")) do
>>   >   if line:sub(1, 1) == "%" then
>>   >     rpm.define(line:sub(2, -1))
>>   >   end
>>   > end
>>   >
>>   > }
>>   > }}}
>>   >
>>   > The issue with this is that the %{SOURCE4} have to be declared prior
>>   this snippet, while I would like to include the macros on the top of the
>>   .spec file in company of other global definitions.
>>   >
>>   > Is there some better solution? Could RPM provide some functionality
>>   along these lines?
>>
>>   Its possible to pass arguments to macros, see
>>   http://rpm.org/wiki/PackagerDocs/Macros
>>
>>   I dont see any bugs here... questions are better asked on the mailing
>>   lists.
>>
>
>
> Hi,
>
> This was originally reported as [1]. I'll just continue here, since this
> issue might get more attention.
>
>
> Ok, so %include works everywhere, but it expects spec file syntax then,
> which differs from macro file syntax.
>
> This [2] is the original source of the script in the original issue [1]
> and the macro file [3] I'd like to "include", which is later installed
> into %{_sysconfdir}/rpm/macros.ruby. But I cannot use plain %include,
> since all the macros defined in macros.ruby would need to be preceded by
> %global.
>
> This is what I tried to follow your suggestion:
>
>
>
> $ git diff
> diff --git a/ruby.spec b/ruby.spec
> index 5436e1f..280d5b6 100644
> --- a/ruby.spec
> +++ b/ruby.spec
> @@ -110,11 +110,13 @@ function source_macros(file)
>     end
>   end
>
> -source_macros(rpm.expand("%{SOURCE4}"))
> +--source_macros(rpm.expand("%{SOURCE4}"))
>   source_macros(rpm.expand("%{SOURCE5}"))
>
>   }
>
> +%expand %include %{SOURCE4}
> +
>   # http://bugs.ruby-lang.org/issues/7807
>   Patch0:
> ruby-2.1.0-Prevent-duplicated-paths-when-empty-version-string-i.patch
>   # Allows to override libruby.so placement. Hopefully we will be able to
> return
>
>
>
> and it fails with:
>
>
>
> error: line 1: Unknown tag: %ruby_libdir /usr/share/ruby
> error: query of specfile
> /home/vondruch/fedora-scm/maintain/ruby/ruby.spec failed, can't parse
>
> Could not execute srpm: need more than 0 values to unpack
>

Hardly surprising if you actually think about what %expand and %include 
do - they dont magically transform one format into something else.

>
>
> In other words, I'd be glad if you can suggest how to replace the LUA
> script by something like %include, which will work or accept my LUA
> script upstream.

http://rpm.org/gitweb?p=rpm.git;a=commit;h=784dfb421924110e4da7da0ca2948a2cf5af36a4

With existing releases, you'll just have to transform the macro file 
into a spec-includable form one way or the other though.

	- Panu -


More information about the Rpm-maint mailing list