Re: OpenPackages update

> > How about this for a procedure:
> > 
> > - do an anonCVS checkout of OP
> > - bootstrap install it
> > - create some an OP pkgsrc/ file that specifies ARK, with its dependency
> >   on Python
> > - Use OP to fetch/build/install ARK
> 
> (already had a cvs checkout..)  This is a different thing
> (nothing wrong with it...); I thought my "procedure" would
> be simpler.  This is not an either/or thing, however.  (And
> I'm cycle-deprived at the moment...)

I suspect both ways will be useful.  If folks download OP first and then get
the pkgsrc/ files for ARK, they'll use OP to bootstrap into ARK.

If folks already have ARK, getting a team file for OP will let them grab and
install that.

Having said that, I'm hoping we can can come up with a way to generate ARK
package team files from OP pkgsrc files (or vice-versa).

Again, I want to use these tools in configuration-management environments.

This means I'd like to see a GNU mechanism team that has a useful number of
different versions of different GNU packages, and then we could have a GNU
policy team or few that specified:

- the subset of GNU packages that we want
- the particular versions of each package
- special options (prefix with 'g' or not)

H