Re: My personal pkgsrc FAQ

["Justin C. Sherrill" <justin@xxxxxxxxxxxxxxxxxx>]

On Tue, December 16, 2008 9:21 am, Hasso Tepper wrote:

> There have been several persons jumped in in the past with "hey, I'll do
that bulk stuff", but disappearing after that. What we need is person
taking care of _regular_ bulk builds in long term so that security fixes
can be applied by users in timely manner etc. So, that users can rely on
these packages.

I'm thinking you mean me, or partly me, as a flake - I did have bulk
builds on pkgbox, but they've not been regular, for a variety of reasons.

> If there will be person who is willing to invest his time into
maintaining
> builds, we have more to discuss (for example default options for our
official builds etc), but so far there is no point ...

I'd be interested in ideas.  What are the default options that might be
useful?  pkgsrc has a lot of knobs, and I'm definitely not familiar with
them all.

One of the puzzles is how we can create a set of packages right at release
time.  pkgbox.dragonflybsd.org is a good place to build, but Matt's
bandwidth is not high enough to move the packages out to mirrors
efficiently, and it does take a week to produce the packages on that new
release.

Would it be relatively 'safe' to, as soon as we get within 2 weeks of a
release, rebuild pkgbox with HEAD (so to speak), and then start a bulk
build with the most recent quarterly release?  From then on, keep pkgbox
at that DragonFly release, rebuilding that quarterly pkgsrc release until
the next pkgsrc quarterly comes along, or the next DragonFly release? 
These are two semi-desynchronized releases, so this is my best guess right
now on how to coordinate.

We could build bleeding edge DragonFly and pkgsrc on a separate machine;
Matthias has given me some space on his development system to do so, but

The bandwidth from dragonflybsd.org is pretty low; a new quarterly release
causes a sudden jump in data to send out.  I'm not sure how to address
this issue.

I'd like to have a better mechanism for remote binary package
installation.  pkg_radd works surprisingly well for such a simple script,
but I'd like something more polished.  Something that integrates building
from source when bianry packages aren't available would be good; the
BINPKG_SITES variable had some potential.