Longer term it may well make sense for there to be one or more developers with commit access to ipp and pkgsrc, but I think it best to focus on an initial pass of cleaning things up first.
Yes, this would be very useful. Btw, Emile "iMil" Heitor is part of this project too. This project is still very young, and still needs a lot of cleaning, even though we already can build more than 6300 packages.
CVS tends to be a relatively inefficient mechanism for an initial pull of pkgsrc, so a better approach for initial sync might be via http/ftp and extract.
That could also provides the pkgsrc tree to allow building a cvs client if required to ensure any future update is easy. We still have to address using the correct command to download on each OS, but that should not be overly difficult.
Acctually, the first versions of our wrapper script did a initial download via http/ftp, maybe we should implement that again.
This is very much OS specific. I personally would have no problem in having an optional per OS script delivered with bootstrap which could be called to verify that required dependencies are found, and optionally download and install them.
The expectation would be that a given site could override that script without needing to modify the standard bootstrap file.
This could easily be done with wrappers, but if there is a standard way of handing this on OS 'x' then it would be reasonable for bootstrap to optionally be able to call it, and certainly for it to (non fatally) warn if anything expected is missing.
Yes, I know this is very OS specific, so we just leave to our wrapper.
I think this one is quite interesting, particularly the management of different prefixes. Could you expand a little on how you would see that working - where would you store details of bootstrapped localbases and their configurations for example?
I can tell you how our wrapper script (ipp) currenly do this.
To make a standard bootstrap (/opt/ipp/pkg):
# ipp bootstrap
To make a new localbase called test (opt/ipp/test):
# ipp bootstrap -e test
All this is done by a bootstrap --prefix=/opt/ipp/{localbasename} and means that VARBASE goes into /opt/ipp/var and PKG_DBDIR into ${VARBASE}/db/pkg.
If you run:
# ipp localbase -l
it will list all the bootstraped localbases located under /opt/ipp
If you run:
# ipp localbase -r test
it will remove the localbase called test
If you run:
# ipp install <category>/<package>
it will install <package> form <category> into default localbase (/opt/ipp/pkg)
If you run:
# ipp install -e test <category>/>package>
it will install <package> form <category> into localbase named test (/opt/ipp/test)
This definitely sounds interesting. You could go to the extreme of bootstrapping in one prefix using the host compiler far enough to build the preferred pkgsrc compiler, then use that compiler to bootstrap into the target prefix, which gives you a self built target compiler...
Well, our wrapper is not that fancy yet, it only bootstraps, install the pkgsrc compiler, rebuild needed packages, and adds PKGSRC_COMPILER=<compiler> to mk.conf. Maybe your idea is worth looking at.
I would expect this should be covered by updating the various files in mk - particularly mk/platform and mk/tools (or PKG_JVM_DEFAULT in
java-vm.mk).
A standard mk.conf *should* work for
Illumos/Openindiana. Anything else is a bug in pkgsrc :)
I/we'll investigate these files, and report back.
We have prior art in pkgtools/gensolpkg and pkgtools/genrpm. I see no reason why a genips would not be welcome.
Yes, why not let the world benefit from this wonderful build system?
Cheers,
Mads Worsøe Duun