RPM Community Forums

Mailing List Message of <rpm-users>

Re: Project "RPM Spec file creation guidelines"

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 29 Dec 2008 - 14:44:50 CET
Message-id: <E2DB5B1D-EC69-4497-AEAD-D8A00D6D1FB0@mac.com>

On Dec 29, 2008, at 4:33 AM, Anders F Björklund wrote:

> Eric MSP Veith wrote:
>
>> On Thursday 25 December 2008, Jeff Johnson <n3npq@mac.com> wrote:
>>> Creating "good, nice-looking spec files" is hardly related to
>>> the primary goal for package management which is
>>> 	Delivering content to user file systems reliably.
>>
>> I was refering to Anders' comment:
>>
>>> There is a dire need for an updated book on RPM Packaging, something
>>> that seems to happen every 5 years or so. (e.g. Max RPM and RPM  
>>> Guide)
>>>
>>> But if you have ideas, do bring them up here or on the rpm-devel  
>>> list -
>>> maybe they would be useful for everyone and could be included  
>>> upstream ?
>>
>> I just thought that there's a need for RPM packaging documentation,  
>> for a
>> collection of "best practice" guidelines. If rpm5.org and the RPM  
>> ML is the
>> wrong place for this, I'll just post them somewhere else. :-)
>
>
> The immediate context was the addition* of a "%{__makeinstall}" macro
> instead of using "%{__make} install". Added a %{__fakeroot}, I  
> believe.
>
> * http://rpm5.org/community/rpm-users/0265.html
>

Ah, got it. Yes %{buildroot} -- unlike every other macro -- has a FIFO
semantic (i.e. the first, not the last, definition "wins")

Along the lines of @rpm5.org "features" in need of documentation is
the "readonly" operator for macros that is the generalization of
FIFO <-> LIFO precedence when defining macros.

Normally macro values are stacked, and the last definition ends
up on top-of-stack and is the value used when expanding a macro.

So the primitive %undefine is the same as a stack pop, while %define
is the same as a stack push.

The %{buildroot} macro had some complicated testing internal to rpm code
to ensure that the first definition was always used, contrary to
the general rules for macro definitions, so that BuildRoot: could
be overridden everywhere reliably.

A "readonly" operator, prefixing a macro name with a '.' to
prevent further re-definitions, was added. Note that the '.' character
prefix is __NOT__ part of the name "foo" in
	%define .foo some_value_here
or
	%.foo	some_value_here
but rather a "readonly" attribute attached as a prefix.

> But it did seem that RPM 5.0 packaging could need some documentation,
> instead of keeping up with the various vendor dialects of RPM 4.4... ?
>

Absolutely there is need of better documentation, that is always true.

But vendor dialects to solve vendor problems are a fact of life. The  
vendors
are all solving the same problem(s) in different ways to increase the
value of their products. I'm not sure how to engineer a solution for
vendor dialects, its mostly a business/economic problem imho.

But I'm perfectly willing to listen to better ideas.

73 de Jeff

  • application/pkcs7-signature attachment: smime.p7s
Received on Mon Dec 29 14:44:55 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.