On 3/2/08, Jordan K. Hubbard <[EMAIL PROTECTED]> wrote: > > On Mar 2, 2008, at 4:58 PM, Randall Wood wrote: > > > I would like to see MacPorts use RPM for its installation database > > instead of whatever we have now. > > > We don't have anything now. We've also tried to use rpm at various > times in the past, but the impedance matching requirements have always > proved problematic (rpm expects its packages to be built via srpms and > dependencies to be handled in a very specific way, just to name two of > many). > > My personal opinion is that we should start building xar files. > > For the first cut, they can be essentially dumb and we can focus on > extracting enough dependency information from them to do package > dependency tracking. That's pretty straight-forward and quite > achievable with existing technology. > > For the second cut, we can embed a minimal macports runtime (in the > form of a universal dylib and some collection of tcl files) in each > xarball, allowing us to run the same install/post-install/activate/ > post-activate routines at install time. A properly formed package > represents, after all, little more than everything up to and including > the destroot phase, archived up. It's what to do with the specialized > actions (add user foo, present message bar to the user, etc - just > grep through dports looking for post-install to get a good feel for > how varied the landscape currently is) and how to provide the same > activate/deactivate metaphor for packages that has always held us up > > Once we get to that stage, we can behead the current installation > procedures for macports and turn that into pkg install actions. Then > macports just needs to carry the load up to the destroot / package > stage and then hand things off to the package system for the install/ > activate heavy lifting. But, we also need to crawl before we try to > run, which is why I think simple archives (which work for all the > "simple" ports) is the right place to start. Excellent SoC project!
Whichever the student feels like then...I don't really care except that I am becoming more and more familiar with RPM as I now work in a shop[1] that uses Red Hat Enterprise Linux 5 as the basis for all its products. As far as the complexity of RPM goes, I think that a lot of the dp-light work is still hanging around and may be reusable, but it may simply be a good idea for port to do a Portfile to .spec file transform (and maybe build the SRPM) and then hand everything off to an RPM-based configure/build/distribute/install process. I know that a lot of the GTK/GNOME ports already build the .spec files for creating the [S]RPMs anyway. [1] Trusted Computer Solutions (http://www.trustedcs.com) -- Randall Wood [EMAIL PROTECTED] "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
