tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: inquiry regarding "best practices" for chrooted pkgsrc development and other things

Blair Sadewitz <> writes:

> I would like to do all of my development and package building in a
> sandbox to help me catch pkgsrc bugs as well as my own errors.  Is
> that overkill?

I find it overkill. These days, you can build and with "make stage-install".
On the other hand, you may deploy plain chroot (with "MAKEDEV std"),
it is enough to make pbulk happy.

> I only have one xen instance to play around with for the time being.,
> though it does have 4 vcpus and ~40GB of disk

40 GB isn't enough if you plan to run bulk builds.

> There are so many options, and I'm still stuck on how best to allocate
> my disk space.

I have found that these days it is better to have just one big /.
At least I consider it the best until we grow in-place resizable file systems.
(And I do suggest it strongly to novice users, since it is really hard to
estimate your requirements correctly ahead of time and hard to fix it
after you discover that your requirements has changed.)

> I don't _have_ to put myself through this, of
> course; I could have just created one large partition and done all of
> my development in one tree without caring about correctness, overuse
> of superuser privileges, etc, but I'd like to start out doing this
> right.  Not that I don't enjoy spending hours on sysadmin tasks
> without getting anything done, but ... ;-)

If you cannot afford installing into global /usr/pkg, do it in unprivileged 
(I used to do this in some past, it works just fine) or in /usr/pkg-devel
(slightly similarly to what <riastradh> does). Alternatively, do it in
the chroot environment, though it does overuse your superuser privileges.

I use three pkgsrc trees, one unmodified from anoncvs so that I can
revert fast without thinking about saving my modifications, one for
development from anoncvs (so that I don't commit anything accidentally),
one for committing changes. Most of the process is done unprivileged,
only package installation is privileged.
describes my usual development process.


Home | Main Index | Thread Index | Old Index