Ralf S. Engelschall wrote:

> Some status quo on RPM 5 from my personal point of view:
>
> As you perhaps recognized yourself, just about 4 weeks ago building
> RPM was (sorry that I have to say this) still more or less a real
> nightmare -- even for a hard-core developers.
>
> I personally even was under the strong impression that beside our RPM
> master (Jeff) there could have been only a hand-full crazy people out
> there who ever were able to successfully build RPM -- or at least only
> under Linux or even RH-derived platforms ;-) During the last weeks I
> even had some sort of a déjà vu as all this reminded me very much about
> the year 1995 when I worked-off the similarily twisted and nasty Apache
> build environment for Apache version 1.3...

RPM was indeed built and used for the old OpenDarwin installer (RPM  
4.0.4),
and for the RPM4Darwin project (RPM 4.2-4.3) and some other Mac OS X  
users.
But you are right about the amount of hacks involved, and about how many
people were actually building it and probably about their mental health  
:-)

Both the OpenDarwin and RPM4Darwin projects are now pining for the  
fjords,
but have moved on to Mac OS Forge and wraptastic.org/rpm5.org  
respectively.

> As you know, I'm still strongly following my personal RPM 5 agenda
> (http://trainofthoughts.org/blog/2007/06/05/rpm-relaunched/) and have
> still not reached the end of the rocky road. Nevertheless, on this road
> of completely working off the extremely convoluted RPM build  
> environment
> and fixing all portability issues, we now reached at least a very big
> milestone today, because:
>
> 1. except for very small and harmless hacks, the RPM 5 build  
> environment
>    is now really acceptably clean and mostly untwisted
>    again. Especially, mostly all hard-coded (and often even
>    distribution-specific) installation paths and other nasty hard-coded
>    things are gone. One even can install RPM now with even a GNU-style
>    filesystem layout instead of the default Linux/LSB filesystem  
> layout.
>    And not to mention the fact that RPM 5 since recently finally
>    provides a very flexible and clean way build against the numerious
>    third-party libraries. Something which required really lots of
>    hacking for distribution vendors in the past.

This sounds excellent, looking forward to working with rpm5 proper -
something I haven't had the time for yet while entrenched in rpm4...

Meanwhile I have updated the MacPorts internal package system to use
rpm-4.4.9 and popt-1.11, with rpm-4.5 and popt-1.12 upgrades pending.
Since that's now mostly working, the time has come to try rpm-5.0 -
both standalone Mac OS X, and eventually using the OpenPKG version.

> 2. all essential portability fixes and code cleanups were applied, so
>    the code now builds about in 99% of the cases really cleanly on
>    arbitrary Unix platforms. Just a few very minor (but technically
>    harmless) issues remain.

Sounds great, I was especially interested in the FreeBSD/Darwin ones.
MacPorts RPM should be working OK on Mac OS X, FreeBSD, and Darwin...

> 3. as requested multiple times by Jeff and others during the last  
> weeks,
>    I've now finally integrated my complete scripts into the RPM 5
>    "devtool" environment under the "%standalone" target for allowing  
> RPM
>    developers to build RPM 5 on an nearly "arbitrary" Unix platforms
>    and to now especially also have an additional _real-life_ "use case"
>    at hand. The "%standalone" is a real-life use case because the code
>    of "%standalone" is about 95% the code I'm planning to use soon in
>    the OpenPKG "bootstrap" package for building RPM 5. Nevertheless,
>    don't panic: the %standalone is really completely independent of any
>    OpenPKG-specifics.

MacPorts RPM uses the "port" build system to drive rpmbuild through
auto-generated spec-files, so it will be another RPM-using platform
even though it also supports the Mac OS X Installer packages (.pkg)
along with some other formats. (e.g. "port rpm foo", "port srpm bar")

I will also build a standalone version (without MacPorts dependencies),
that will work more similar to what the old RPM4Darwin installation did.

> 4. I've fixed the build environment to again support GNU-style building
>    from an _external_ build directory. This especially now allows one
>    to build and develop RPM within a _SINGLE_ source tree on a cluster
>    of servers in parallel. Together with (3) from above this allows one
>    to easily build and develop RPM 5 on a number of totally _different_
>    Unix platforms (for instance FreeBSD 6, Fedora 7 and Sun Solaris
>    10). I used this now to make sure that RPM 5 builds, installs and
>    at least trivially works under run-time on at least the following
>    particular Unix platforms (where "platform" means an architecture  
> and
>    OS combination):
>
>      ix86-freebsd6.2
>      amd64-freebsd6.2
>      ix86-freebsd7.0
>      ix86-fedora7
>      ix86-debian3.1
>      ix86-debian4.0
>      ix86-rhel4
>      ix86-solaris9
>      sparc64-solaris8
>      sparc64-solaris9
>      sparc64-solaris10
>      amd64-solaris10
>
>    The procedure I used I've documented in detail under "BUILDING RPM  
> ON
>    A CLUSTER OF SERVERS" in the latest version of the INSTALL document.

Will test it on i686-apple-darwin8.9.1 and powerpc-apple-darwin8.9.0
(or ix86-macosx10.4 and ppc-macosx10.4 as OpenPKG/shtool calls them)
i.e. the platform is Mac OS X 10.4 "Tiger" Universal (PowerPC / Intel)
will upgrade to 10.4.10 once Apple releases the Darwin source code...

I don't have Leopard yet, and even if I did we couldn't talk about it.
Q: Did you get build access to Mac OS X yet, or is that still a TODO ?

> So, in short: if you ever wanted to give RPM 5 a try, I think _NOW_
> is the first time you can do this in a reasonable way -- even if you
> are not a hard-core developer. From my point of view, RPM 5 now is
> in a rather good shape and can easily enough be build by an average
> developer. I hope this also helps to somewhat enlarge the RPM 5
> developer community or at least gives us some more testers.

Excellent news, have already used some of the code (i.e. back-ported)
for improving the rpm-4.4.9 port and will do the same for rpm-4.5.0
(eventually there'll be a "rpm-devel" port for trying rpm-5.0.0 too)
http://trac.macports.org/projects/macports/browser/trunk/dports/ 
sysutils/rpm

> After about 6 (unfortunately unpaid) man-weeks of very extensive
> development on RPM 5, I personally have soon to throttle my amount
> of development time I spend on RPM 5 as I've to finish some
> business-related project management certifications first and I also
> have to earn a living (at least until someone is willing to pay me for
> further hacking on RPM 5 ;-). Nevertheless, I'm very pleased with the
> strong progress and especially the resulted very good shape of RPM 5.

Thank you for your major effort on updating RPM 5! Taking summer  
vacation
myself, but looking forward to working on RPM 5 (with a GUI) for Mac OS  
X
when I return here in August. I'm sure that there will some exciting new
features on the XAR front by then as well, so lots to look forward to...

Enjoy Summer,
--anders