On Feb 18,  8:52am, Joerg Sonnenberger wrote:
} On Fri, Sep 28, 2007 at 04:39:56AM -0700, John Nemeth wrote:
} >      Perhaps if you were to detail exactly what this means, we would
} > have a better basis for discussion.  For the sake of argument, let's
} > say you get to remove pkg_install from base for NetBSD 5.0.  Tell the
} > complete list of steps that a user would need to do after installing
} > NetBSD 5.0 before they could type 'pkg_add <some random binary
} > package>' (assume that said package can successfully install and run on
} > the user's system).
} 
} Variant 1 (for "official" release builds):
} The user selects the pkgsrc set (or whatever it should be called) during
} sysinst. That's all.

     This is fine.  I'm assuming that this means that sysinst would
take care of installing the pkgsrc tools.

} Variant 2a (for "custom" builds):
} The user doesn't select the pkgsrc set or wants a newer one from
} scratch. She fetches a pkgsrc tree and runs bootstrap/bootstrap.

     I don't have a major problem with this.

} Variant 2b (still for "custom" builds):
} Before running build.sh, the user also gets a pkgsrc tree and sets the
} MKPKGSRC option (or whatever) similiar to MKX11. The bootstrap is
} cross-compiled as part of the release build.

     I assume this goes for official release builds as well.  I don't
know what releng will think of this idea.  The problems that I see are
having to have a pkgsrc checkout available and how to ensure that
release builds are reproducable.  Of course, with heading towards
removing X from base and switching to modular X.org from pkgsrc, these
problems will need resolving anyways.  The remaining question is what
about syspkgs should they ever come to fruition.  Would these require
the same thing, or would they require their own tools which would come
with base?

}-- End of excerpt from Joerg Sonnenberger