Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Best practices for development workstations (http://www.linux-archive.org/debian-development/348875-best-practices-development-workstations.html)

John Goerzen 03-30-2010 12:03 AM

Best practices for development workstations
 
Hi folks,

I'm trying to solicit comments on what people are using for development
environments and how well it's working. Here are some situations I
imagine are common:

1. workstation running sid

I've followed this model for over a decade. It works well, in general,
and I keep up with development well enough that I can fix problems when
they arise. However, it tends to lead to a certain amount of cruft over
the years. Moreover, it's not really appropriate for a laptop or a
situation in which Internet access isn't readily available to fix
problems. I'm hoping to move away from that model.

2. workstation running squeeze or lenny

I'm enjoying squeeze on my laptop and am considering switching my
workstations to it. That, of course, means I will still need a sid
environment somewhere for building. It also means that there are times
when the packages I build for sid will not be installable on my
workstation, which could be annoying. On the other hand, breakage
should be more rare.

It will require some solution for sid, though.

2a. pbuilder

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.

The ability to easily rebuild a chroot is appealing. However, I do not
have a fast mirror at home; my "broadband" connection is just barely
broadband. pbuilder highly recommends a local or a fast mirror. So I
am concerned about this approach for security reasons as well.

2b. Xen, KVM, qemu, or VirtualBox

The advantage of this approach is that it provides more complete
isolation from the host workstation. I need not worry about it firing
up a second copy of cron, for instance. On the other hand, it will have
less perfect integration with the host environment (though NFS and ssh
could probably let me write a script like pdebuild). It will also
consume more resources, and especially more RAM and disk space, neither
of which can be as easily scaled up and down in this setup.

There is qemubuilder, but it seems to not support KVM, alas.

Suggestions?

-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BB13FB4.4070901@complete.org">http://lists.debian.org/4BB13FB4.4070901@complete.org

Russ Allbery 03-30-2010 12:43 AM

Best practices for development workstations
 
John Goerzen <jgoerzen@complete.org> writes:

> 1. workstation running sid

> I've followed this model for over a decade. It works well, in general,
> and I keep up with development well enough that I can fix problems when
> they arise. However, it tends to lead to a certain amount of cruft over
> the years. Moreover, it's not really appropriate for a laptop or a
> situation in which Internet access isn't readily available to fix
> problems. I'm hoping to move away from that model.

> 2. workstation running squeeze or lenny

> I'm enjoying squeeze on my laptop and am considering switching my
> workstations to it. That, of course, means I will still need a sid
> environment somewhere for building. It also means that there are times
> when the packages I build for sid will not be installable on my
> workstation, which could be annoying. On the other hand, breakage
> should be more rare.

I use a combination of the two of these except with testing on my primary
workstation (the one that I can't afford to have go down), but list and
deprioritize sid in sources.list on the workstation running testing. Then
when testing builds of my own applications, I let apt resolve dependencies
from unstable where needed.

I've never had any trouble with running sid on my laptop other than
occasionally finding bugs (which is one big advantage of doing this; I
find and report bugs). I just don't do upgrades while I'm travelling. I
wait until I'm home again and have access to other systems and ways of
repairing the box.

> 2a. pbuilder

> 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 do all my builds with pbuilder and cowdancer, but don't do testing in
that environment. I've never had problems with weird things happening
during the build itself.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87iq8e8wrp.fsf@windlord.stanford.edu">http://lists.debian.org/87iq8e8wrp.fsf@windlord.stanford.edu


All times are GMT. The time now is 11:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.