On Tue, Mar 30, 2010 at 8:03 AM, John Goerzen <jgoer...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e13a36b31003291802y5b1f9133ke14249807dc7f...@mail.gmail.com
