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 <[email protected]> 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. > > JMHO, YMMV. > > 73 de > Jeff______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List [email protected] ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List [email protected]
