binary rpm repos?

[Anders F Björklund]

Alexy Khrabrov wrote:

> It turns out RPM works fine on Mac:
>
> http://rpm4darwin.sourceforge.net/

There's also a couple of RPM ports in MacPorts, and a "port rpm" target
to package any port up as a binary package or "port srpm" for source  
rpm.

See http://guide.macports.org/#using.binaries

The standalone installations of RPM work too, but install to /usr/local.
Usually these build from Specfiles or *.src.rpm, rather than Portfiles.

Perfectly reasonable, but somewhat off-topic.

> -- why not have reference binaries for all ports in RPM format, to
> avoid endless recompiling if you don't have to?  Watching gobs of
> compiler output fly by doesn't make one a Unix expert, in the immortal
> words of the funroll-loops.info of the "Gentoo is Rice" fame.  Yeah,
> yeah, it depends on what you have -- but look, Red Hat does it!

Normally MacPorts turns off the spew unless requesting it with port -d,
but yeah you still have to install Developer Tools and do the rebuilds.

There were binary rpms built for MacPorts 1.3 and 1.4, but not for
1.5 and 1.6 mostly due to the lack of interest. For MacPorts 1.7 it
seemed "easier" to use the built-in archives, due to the heavy usage
of "variants" and the missing integration of the "dp_light" branch...

So at the moment, RPM is an "external" packaging system while the only
integrated is the "internal" archiving systems of e.g. TxZ or XPKG*.

* http://web.archive.org/web/20061230221957/http://www.xpkg.org/

This means that if you install a port from a RPM package (or from a PKG)
then the registry and port(1) command still won't know anything about  
it.

An example: "/opt/local/bin/port is not provided by a MacPorts port."

So you would have to build (and rebuild on any updates) every port that
you want to install as a package first, as you can't mix ports/packages.
One of the problems is that variants (+) are not recorded by the  
packages,
so you set those when building (normally it just uses the default  
variants)

--anders