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 <firstname.lastname@example.org> 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: …
> 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.
> JMHO, YMMV.
> 73 de Jeff______________________________________________________________________
> RPM Package Manager http://rpm5.org
> User Communication List email@example.com
Received on Tue Mar 27 07:43:50 2012