Re: OpenPackages update

Harlan writes:

> OP is a portable implementation of the auto-dependency,
> -download, -patch, -configure, -build, and binary
> packaging system used by the *BSD projects.

I agree with Harlan that this is potentially Very Cool!

> The last time I looked, the "auto fetch" part of ARK was
> not yet implemented, and there was no great way to handle
> applying patches to stock distributions.

Boring reasons, IMO.  The main benefit of OP is if we can
"subcontract" lots and lots of packaging stuff/details to
people who really/only/totally care about such things.

> We're just about at the place where OP will bootstrap
> itself and pass an initial sandbox test, and I think we're
> just about ready for some early adopter and tester folks.
> Any takers?

I'm game at least to noodle with it.  Here's what I'd
suggest:

* Install the initial OP stuff {by hand,outside of ARK land}

* Create a new team ('op', 'openpackages' ?) and start
  creating some proto-packages in it; the bare minimum is ...

  mkdir <op>/package/ALL.xml

  (You've taken the lead, Harlan, so you get to name the
  team :-)

* If you want to start of with it doing Truly Nothing, copy
  sidai/package/null.xml into it.

* In your site team, where you currently have (in, say,
  zsh--4.0.1) ...

   <prototype team="sidai" name="GNU" />
   <prototype team="."     name="ALL" />

  ... change it to:

   <prototype team="op"    name="ALL" />
   <prototype team="."     name="ALL" />

* Try it -- type 'ark package compile zsh--4.0.1'.  Make
  Jolly Sure that the 'compile' method actually does
  whatever OP does when it "compiles".  Ditto for other
  methods.  For any methods that "make no sense" in OP land,
  just leave them null'd out.

* If you have to do special OP things in order to build,
  say, emacs, put the magic in the relevant proto-package,
  e.g. op/package/emacs.xml  (i.e. the equiv to what we've
  done in Sidai)

Once that works, it's just a SMOP to finish the job :-)

Will