Re: pkgsrc and robotpkg

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Fri, Nov 19, 2010 at 12:15:04PM +0100, Anthony Mallet wrote:
 > The fact is that robotpkg started as an attempt to teach our
 > students the notion of "package", "release", "installation" etc. in
 > the software they develop.

This is surprisingly difficult, IME.

 > | How does it differ from builtin?
 > 
 > This is the big point. The robotpkg mechanism differs from builtin
 > in that the "builtin" feature is systematic, for all packages. Any
 > package can be configured (by end users) to be either "system"
 > (external) or "robotpkg" (internally managed). For "system"
 > packages, robotpkg checks the presence of a few representative
 > files of the packages (like some headers, .pc files etc.), then
 > report about the installed version found, the installation prefix
 > etc. so that the configure step of a package can be told where its
 > dependencies are living thanks to variables like PREFIX.pkg,
 > CPPFLAGS.pkg etc. And some of the packages that will never be
 > packaged in robotpkg have only a "system" version in
 > mk/sysdep/xxx.mk (no Makefile, PLIST etc.).

This is, however, exactly how pkgsrc builtin works -- the only thing
that stops it from being universal is that someone has to go through
and for each package specify how to recognize the builtin form safely.
(And perhaps equally importantly, how to figure out what version it is
in case that version isn't recent enough.)

Have you done this for every package, or have you set up an automated
mechanism for finding builtin packages, and if the latter, how does it
work?

 > | make extract SKIP_DEPENDS=yes
 > | make help topic=SKIP_DEPENDS
 > 
 > Thanks! I was actually not aware of this (this used to be NO_DEPENDS iirc).
 > 
 > But again, while I am myself very happy with typing
 > "SKIP_DEPENDS=yes", this is not true for the users of
 > robotpkg. They actually expect this to be the default behaviour,
 > and this actually makes sense I think. But that's definitely a
 > detail.

Arguably I do too; it doesn't make sense to have to build deps before
you can untar something. I guess it's desirable this way if you're
doing a large build, because then all the deps can be built and
cleaned before taking up disk space with the extracted copy, but that
seems like it should be handled under the covers. (That is, have the
configure stage depend on both the deps and the extract stage, maybe
with a .WAIT in between, rather than having extract depend on the deps
directly.)

-- 
David A. Holland
dholland%netbsd.org@localhost