Re: Best practices for development workstations
On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen <jgoerzen@complete.org> wrote:
> 1. workstation running sid
I used that until DebConf9 when I reinstalled and switched from i386 to amd64.
> 2. workstation running squeeze or lenny
At the moment I have only one workstation (a laptop). I use testing,
unstable and experimental, with pinning setup to upgrade within that
suite where I've upgraded a package, until the version migrates to a
lower suite.
This is not a total insurance against unbootability, for instance, due
to the fact that my system sometimes needs to boot from USB and grub
not being able to install itself to the disk a UUID/LABEL is from
(only a specific device like /dev/sda) , my /boot/grub got out of sync
with my MBR and grub couldn't find the right files so I needed Debian
Live to recover from this.
One problem with this approach is that you aren't helping to test sid,
filing bugs and so on, instead letting others do that work. If many
folks do this, testing will get more buggy over time. I plan to
rectify my contribution to sid by getting a fast desktop computer and
using that for testing sid.
My phone (OpenMoko) also runs Debian (and SHR, an OpenEmbedded-based
distro) too, I use the same setup as above, with one difference; my
pinning prefers stable, but sources.list doesn't reference lenny.
Probably I'll default to stable after squeeze is released.
> 2a. pbuilder
I'm using the cowbuilder variant of this for now.
> pbuilder, or some other chroot such as schroot, can help. In theory, it
> is a good plan. I don't have to dedicate a lot of RAM to it. The
> problem is that a chroot doesn't establish terribly strict separation
> from the main environment. Despite promises to the contrary, I've had
> weird things happen; for instance, an MTA, database server, or some
> other daemon process might try to fire up from within the chroot, which
> can result in highly confusing situations. I am therefore somewhat
> uncomfortable with this prospect.
I've had problems with cowbuilder to, lighttpd FTBFS during [1] due to
lots of its tests failing.
1. http://wiki.debian.org/DebianThailand/MiniDebCamp2010/BSP
> So I am concerned about this approach for security reasons as well.
Could you detail your concerns here?
> 2b. Xen, KVM, qemu, or VirtualBox
qemu is too slow and my laptop doesn't have CPU virt bits so no KVM. I
used VirtualBox once when I was working on lilo RC bugs. I'd like to
use something more lightweight like LXC (or vserver) as a
pbuilder/sbuild backend at some point, haven't had the time to
investigate yet though.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: