Re: %iflibcversion %ifnlibcversion

[Jeff Johnson <jbj JBJ ORG>]

On Wed, Jul 18, 2001 at 06:12:04PM +0200, Peter A Jonsson wrote:
> > What's needed in rpm is a well defined, portable, and reasonably complete
> > set of tests and predictable name space, much like autoconf wrto config.status,
> > not more arcane --  compiled into rpm --  spec file syntax IMHO.
> 
> That would be ideal, yes. This was however a fairly trival patch and someone 
> might have use of it until rpm does this in a cleaner way. Thus my posting.
> 

Patches to rpm are always appreciated :-)

> How do you want it? It is better if I spend my time on fixing things that will 
> go in upstream rather than keeping a local repository with patches that needs 
> fixing for every release of rpm.
> 
> %if (os(Linux) && 
>      (version(libc) => 2.2))
> ..
> %elseif  (os(Linux) && (version(libc) < 2.2))
> ..
> %else
> ..
> %endif
> 
> Is an alternative, maybe? That would make the specfile harder to parse though. 

Let's back up a moment, as syntax problems are always pretty easy to solve.

What packaging problem are you trying to solve that needs libc_version?

Do you really care what the libc version is, or are you actually interested
in some implementation detail that just happens to be in the 2.2 library? The
difference is what is being tested: If you test explcitly for the detail
(rather implictly on the version where the detail happens to be located),
your test will not break if the detail were, say, to be backported. A
test on glibc version also suffers from beacoup portability problems to
non-linux systems.

Is there any alternative, with, say, better tests in rpm scriptlets, or
with a patch to configure, to achieve the same packaging goal? My reason
for asking is that I firmly believe that %ifarch etc in spec files is
just not the Right Thing To Do in the long run, rpm is already pretty bad
at building (as opposed to packaging) software. JMHO.

Can the test be factored out of spec files and into build system configuration?
Many problems currently being "fixed" in spec files just cause problems when,
say, the package is cross-compiled, or built on an oddball platform.

What are the underlying semantics (read: how the heck is rpm supposed
to figger libc version?) If the answer is something like
	echo "%_libc_version 1.2.3.4" >> /etc/rpm/macros
then please start thinking about how/when/where the configuration
can be autogenerated reliably and portably ...

> 
> > Here's a cheaper variant (entirely untested):
> > 
> > %{exapnd: %%define _libc_version %(<your test here>)}
> > 
> > %if %{_libc_version} = "2.2.2"	# <-- I think this works, maybe not
> > ...
> > %endif
> 
> Considering TOK_LOGICAL_AND is defined in expression.c it sounds like there 
> are logical operators in that parser. That is nice.
> 

What's broken is that %if is implemented as part of a line-by-line parser,
while macros are context free. Not everything that begins with a % in rpm
is a "macro". I'll get this fixed eventually (I hope), but there are underlying
design flaws with %if currently implemented in rpm. Just ask anybody :-)

> The "problem" with this would be that specfiles might become cluttered. 
> Testing for libc-version is not very portable, ie a lot of %ifos tags and 
> %endif's would show up. In between that there would probably be quite a few 
> lines trying to do what the test is supposed to do.
> 
> > The %(<your test here>) could be as simple as
> > 	%(rpm -q --qf '%%{version}' glibc)
> > on an rpm managed system.
> 
> Having everything rpm managed makes the above test very simple. In reality, 
> all operatingsystems aren't rpm managed, unfortunately. Packaging Solaris and 
> FreeBSD and whatever else is probably something most people will consider not 
> worth the trouble though.
> 

There are always other tests ...

HTH

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC