RPM Community Forums

Mailing List Message of <rpm-users>

Re: rpm on OSX Lion

From: Henri Gomez <henri.gomez@gmail.com>
Date: Tue 27 Mar 2012 - 07:43:46 CEST
Message-Id: <F6CEAE0A-29FA-4C44-A977-4DF72076F36C@gmail.com>
What a clear explanation. 

RPM is strong by splitting build/runtime dependencies. And its powerfull runtime lifecycle (post/pre/trigger...). 

That's why I'm back in RPM world now I'm working in Continuous Integration and Delivery. 

I should get code from cvs to study devtool so

Le 26 mars 2012 à 23:39, Jeffrey Johnson <n3npq@me.com> a écrit :

> 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
>    Requires: …
> and
>    Provides: …
> 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______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> User Communication List                             rpm-users@rpm5.org
Received on Tue Mar 27 07:43:50 2012
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.