Status Quo:

The RPM build environment is really one of the most convoluted ones
I've ever seen. And I've really seen _MANY_ nasty build environments
during the last decade ;-) The RPM build environment is full of unclean
variable overrides, dozends of hacks and more. Most of the stuff seems
to be just left-overs from RPMs evolution during the last 10 years,
others were just ugly hacks for Red Hat Linux platforms, others were
done by accident, etc.

Following my personal agenda (for more details just see my BLOG
under http://trainofthoughts.org/blog/2007/06/05/rpm-relaunched/) my
ultimate goal is to get RPM 5 building in a _clean_, _straight-forward_
and _consistent_ way under _all_ major Unix platforms, so it
especially finally can be integrated also into the next version of the
cross-platform software distribution OpenPKG (which currently is still
using a hacked RPM 4.2.1). Although I've already completed most my step
5, the RPM build environment is such convoluted and spiked with special
cases that I got thrown back to step 4 ("modernize the Autoconf/Automake
based build environment").

Hence I'm still investigating how to further streamline the
RPM build environment. After many dozends of both surgical and
"sledgehammer-style" commits we already reached a state where the
"monster" named "configure.ac" is in at least in an "acceptable" state
again (all ugly hacks are at least bandaged) and the Makefile stuff is
slowly approaching a cleaner state, too.

Nevertheless, two major points still cause me headaches and hence I've
to still investigate there further. A few details follow in case you are
monitoring me ;-)

1. The "configure.ac" and "make install" code behaves slightly
   different on different platforms. This can be seen an advantage or a
   disadvantage. For me it is a disadvantage because I expect exactly
   the same results under all platforms. Hence, from my POV we at least
   need the possibility to explicitly _fixate_ the installation layout,
   etc.

   By default RPM could still use its current "do it differently
   for various platforms" approach, but IMHO we at least need the
   possibility to fine-tune at least all paths explicitly when needed.
   I'll investigate here and perhaps we need a bunch of additional
   Autoconf options. Reminds me somewhat about my efforts to the
   Apache 1.3 build environment where at the end I had to introduce a
   "config.layout" to make all parties happy. We'll see...

2. Although we finally have a sophisticated way to link against
   the third-party libraries, we still have a related problem: the
   internal copies of third-party libraries are linked differently
   against RPM. "db" is packed directly into "librpmdb.la", "lua" by
   accident is packed into "librpm.la", etc. All not consistent and
   hence confusing and on some platforms even causing problems (Jeff
   for instance got failures with the Lua linking).

   Here I've to investigate, too. I'm still not sure what the best
   approach is, but it should be clear that although the local copies of
   third-party libraries are not explicitly _installed_ (as libdb.la,
   liblua.la, etc) their _content_ has to be installed in some way or
   our librpm*.la are useless in practice. The approach of librpmdb.la
   to include libdb.la seems to be a ticky and acceptable solution
   although it has to be done for _all_ libraries and perhaps the
   third-party stuff should be grouped together (perhaps even in the new
   librpmmisc.la which is some sort of a container for remaining and
   dynamically selected stuff anyway). I'll look what I can do for us...

Watch out for more commits...
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com