[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RPM differences among distros (specifically Mandrake & RedHat)



On Thu, 6 Jun 2002, Bill Rugolsky Jr. wrote:
[..]
> PLD uses %{tmpdir} instead of %{_tmppath}, and used %{rpmcflags} instead
> of %{optflags}.   (The latter two have slightly different meanings, but
> accomplish the same thing.)

$ rpm --showrc | grep tmp
-14: _tmppath	%{_var}/tmp
-14: tmpdir	%(echo "${TMPDIR:-/tmp}")

As you can see %{_tmppath} is standard macro but not used in PLD because
we want use for temporary install package files before produce binary
packages location $TMPDIR depended for have all devel enviroment elents
depend on single point for storing temporary resources (standard
${TMPDIR:-/tmp} location).

I'm point for add this on list ~two years ago or change _tmppath to %(echo
"${TMPDIR:-/tmp}") or even drop %_tmppath and use only %{_tmppath}. After
no Jeff response for minimize changing default macros behaviore we decide
to add additional macro as extension.

Also %rpmcflags isn't the same as %optflags. In PLD macros set it is core
element our %{debug} infrastrusture and it is overlay to %{optflags}. Used
in PLD %{rpmcflags} definition loooks like:

%rpmcflags      %{?debug:%debugcflags}%{!?debug:%optflags}

For example by adding in spec file:

%global		optflags	<foo_optimization_options>

you can control this indepenedently to is package builded in debug form or
not. Why it reqire adding this in above way ? Simple because some packages
requires special optimizations (for example using -O2 (was) produce buggy
binaries).

Yes in other distros without our %{debug} infrastrusture spec files
can be used by assign to %{rpmcflags} avalaible %{optflags} value (for
example in private ~/.rpmmacros).

As you can see pointed PLD macros aren't replacements but _extenssions_
standard macros set. So using in this case "instead" word is incorrect
because this macros do not accomplish the same things :^)

> It would not be difficult to create the "grand unified" macro file, and
> for your personal system this might not be a bad idea.

But it isnt't so neccesary.
Even prepare common macros set do not will guaratied is spec from distro
A will produce package in distro B because this also strnngly depend on
installed in build enviroment packages set.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []