Re: %iflibcversion %ifnlibcversion

[Peter A Jonsson <Peter A Jonsson epl ericsson se>]

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

There are several approaches to any problem ofcourse. The reason the version 
of libc is interesting is because it is an easy way to identify similar 
systems. Gcc 2.95.2 does not build with libc 2.2.2 afaik and patching it is 
beyond the scope of what I want to do. Exiting before starting to build would 
be one possibility. This could easily be handed with %iflibcversion-tag. An 
alternative to that approach is to add more intelligence to our buildtools so 
it does not build gcc 2.95.2 on certain systems. The problem with that would 
be that we manually have to tell which systems not to build it on. It is a lot 
better if the package-maintainer can do something (possibly ugly) to prevent 
that the package is built on systems which contain a too new glibc. Thus, if 
adding new systems one will not need to adjust the configuration for the 
buildtools. A third way could be to implement ExcludeLibcversion. This idea 
does not give the flexibility of adding patches if one so desires.

> 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.

No, I am not really interested in which version it is, nor am I interested in 
implementationdetails. My test of libc-version should of course need to be 
nested with "%ifos Linux" to make sure that it is the correct version under 
the correct OS. I have (yet) no reason to know of libc version for any other 
OS than Linux, hence my test in configure only did something on Linux. If the 
OS was not Linux it would just set it to "1". If anyone needs to add a test 
for Solaris for some reason it is possible, I'm quite sure of.

The basic idea with the versiontest of libc is that one can apply patches for 
programs only under those OS' which they do not build on due to libc-changes 
("changing" sys/time.h to time.h for example).

> 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.

I do not consider a patch to configure a better way. One problem with that is 
that you need to know autotools which in fact a lot of people don't. Second of 
all, all programs don't use configure. The packager should not need to be 
fluent in both autotools, C, C++, TCL/TK and a few other languages. %ifarch is 
fairly easy to avoid so far in my experience. %ifos is far more common though. 
Are there any nice ways to avoid that?

RPM and building software. Hm.. I haven't had any problems with building 
software with rpm, the only problem so far is that it locks the database when 
installing software and if you try to run another rpm accessing the same db it 
just gives up when it notes that the db is locked. This is rpm3 though, rpm4 
might have improved.

> 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.

The basic idea is to take a vanilla redhat installation with as few packages 
as possible (bash, kernel, libc, fileutils, init, X, ..) and without touching 
/ or /usr having a separate self-contained directory with software that "only" 
depends on software in that directory. The reason to have the plain 
installation of the OS is that it is easy to reproduce and anyone can do it 
assuming they use the same version. Changing the system configuration is 
therefore not desirable, then one would need to maintain even more software. 
Cross-compiling is not something that I personally is particulary worried 
about since the systems I use are not cross-compiling.

> 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 ...

My test was in the configurescript. My standpoint there is "If people build 
rpm on redhat 6 and run it on redhat 7 when there are packages for redhat 7 
they are on their own". Adding more OS' in the configurescript is possible I 
am quite sure of, I just haven't investigated how to do it under other ones. I 
am guessing that people eventually when they need to know the libc-version 
under IRIX/Solaris/.. will add that test and hopefully submit it.

> 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 :-)

Is there any special reason rpm is not using flex/bison to parse the specfile? 

/ Peter