RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm on OSX Lion

From: Jeffrey Johnson <n3npq@me.com>
Date: Mon 26 Mar 2012 - 23:39:43 CEST
Message-id: <684EA3B5-8301-456F-B019-FF83BA3A36FB@me.com>

On Mar 26, 2012, at 4:57 PM, Henri Gomez wrote:

> MacPorts team did a tremendous works and duplicating effort may not be mandatory. 

I should explain the fundamental disconnect between RPM <-> MacPorts
(and more generally *BSD) here.

There are build dependencies and there are install dependencies.

These sets are quite different.

RPM is all about install dependencies and binary packaging.

MacPorts (and *BSD) is all about build dependencies.

RPM confuses things further because (in fact) the build <-> install
dependencies are essentially the same because of "dog food"
and creating build systems using binary packages.

MacPorts confuses things further with +variants in build recipes
that are actually attributes on edges between "package" nodes
in the dependency graph. The closest similar analogue in linux
is "flavors" (iirc) usined by Conary from rPath (but there are other
attempts at +foo variants in linux, just none are worth a damn,
including bonds in RPM using --with and --without).

Which comes to what has been attempted with RPM binary
packages built by Portfile recipes but creating *.rpm binary packages.

The port implementation attempted to map "make world" build dependencies
out of port(1) Portfile recipe builds directly into a *.spec template using
with some modest filtering.

At the same time RPM is/was automating what are essentially
install dependencies and also adding those to *.rpm packages.

This leads to rather a snarly mess because
	build != install
dependencies: the graphs are quite different.

Instead of explaining this Yet Again, its literally (for me anyways) to
embed a tcl interpreter, dink a bit with how the port cli arguments
are passed into tcl, and just hijack all the recipes, and rely on
FULLY automated (rather package manual goo) dependency extraction
by rule to fill in binary package metadata without all the associated
discussions that MacPorts volunteers continue to voice.

MacPorts is nicely done. Just they haven't yet the experience
with dependency graphs and binary packaging because of
cultural (like "make world" and *.dmg and bundles) issues.

Short answer:
	I don't think there is sufficient interest in MacPorts in using RPM intelligently.


73 de Jeff
Received on Mon Mar 26 23:39:47 2012
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.