n-nrelease? (Was: Re: 2.0 installer integration)

[Chris Turner <c.turner@xxxxxxxxxxxxxxxxxxx>]

Matthew Dillon wrote:
> 
>     The installer infrastructure is pretty straightforward.  The first
>     thing to do is to do a nrelease build and poke around /usr/release/root
>     (which, after the build is complete, is what the ISO is generated from).
> 

Was poking around with this the other night, and noticed a couple of things:

There are a few packages needed as part of the install not in tree

- bootstrap-kit-20051221.tgz
- cdrecord-2.00.3nb2.tgz
- cvsup-bootstrap-20051229.tgz

(+= installer, which I'm not concerned with at the moment)

with the source set to:

http://pkgbox.dragonflybsd.org/DragonFly-pkgsrc-packages/i386/1.4.4-RELEASE-BUILD/

1) above yields 403 on direct access, presumably directory listing is
denied.. make fetch works, so no biggie
2) cdrecord appears to now be 'cdrtools' in pkgsrc
   (personally verified using an in-house 2006Q4 bulk )
3) cvsup bootstrap appears to be a custom build / tarball
4) pkgsrc bootstrap / mk.conf checks appear to be a bit arbitrary
5) numbered lists should not be taken as overbearing whinyness

1 and 5 aside,

I was contemplating modularizing this for my local needs right about the
time this thread was started, with the goal to be using my site-local
pkgsrc builds of the various items. so :

1) see #5, above
2) comments on modularizing pkgsrc variables,
   including / not limited to:

   a) cat #5 above |sed -e 's:numbered:lettered:'
   b) PKGSRC_BOOTSTRAP_KIT (and possibly a new variable for the
      unpacked pathname for the kit)
   c) adding pointers to a site-local CDRTOOLS and CVSUP package,
      to replace the reliance on external http for functionality, or
      perhaps pkg_add the packages into the build root via some
      make-configured HTTP server

3) would it make more sense for the nrelease to be called via the pkgsrc
   make, so as to inherit all of it's XYZDIR and makefile library
   goodness? or perhaps to set  '-I PKGSRC_MAKEFILES' if that would be
   compatibile / non-conflicting enough to work
4) if #3/XYZDIR, any good way to test for this? ..
   recall seeing something on tech-pkg a while back, but hey, I'm being
   lazy here..

As I recall, there was some earlier discussion about this a month or so
ago, just getting up to speed.. anyhow:

I suppose it would make sense to get some comments so that my local
changes might eventually be more useful to a wider audience - or perhaps
I'm just getting too nit-picky about this and should 'just use it (TM)'..

Thanks,

- Chris