Google SoC 2008

[Randall Wood]

On 3/2/08, Jordan K. Hubbard <jkh at apple.com> 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
randall.h.wood at alexandriasoftware.com

"The rules are simple: The ball is round. The game lasts 90 minutes.
All the rest is just philosophy."