FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-30-2010, 01:02 AM
Paul Wise
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: e13a36b31003291802y5b1f9133ke14249807dc7fbe2@mail. gmail.com">http://lists.debian.org/e13a36b31003291802y5b1f9133ke14249807dc7fbe2@mail. gmail.com
 
Old 03-30-2010, 03:16 AM
Manoj Srivastava
 
Default Best practices for development workstations

On Mon, Mar 29 2010, John Goerzen wrote:

> 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
>
> 2b. Xen, KVM, qemu, or VirtualBox

I have a desktop (and a separate laptop) both running Sid. I
have a virtual machine that runs SELinux in strict mode for package
building on the desktop. I do not test on the build virtual machine;
most of my testing is done on my desktop.

manoj
--
Kill Ugly Radio Frank Zappa
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k4su33ez.fsf@anzu.internal.golden-gryphon.com">http://lists.debian.org/87k4su33ez.fsf@anzu.internal.golden-gryphon.com
 
Old 03-30-2010, 09:14 AM
Wouter Verhelst
 
Default Best practices for development workstations

On Mon, Mar 29, 2010 at 07:03:00PM -0500, John Goerzen wrote:
> 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.

I've been in this situation ever since I upgraded from potato to woody
back in late 2000, right before I became a Debian Developer.

I've continued this practice on my work laptops that I often have to
take to customers to work -- so they have to work reliably for me.

There've been cases where sid has been broken when I needed the laptop
for work, but these have been rare; and in the nine years that I've now
used it, I can count only two times when it had an impact on my work:
yaboot once broke, refusing to boot the laptop, and of course I only
noticed when I was off-site, away from rescue CD's and had to use it to
give a presentation. This was then done without slides, obviously.

The other time was with the XFree->Xorg transition, when my X server
wouldn't work for a few days and I had to use the laptop at a customer's
site to configure something on their network. It was a little awkward to
have to explain why I didn't have a graphical user interface, but I
still could do my work, so it wasn't a problem as such.

Of course, sid does require you to do a little more hand-holding, and
this can be annoying at times. But if you stay up-to-date with things,
I find that it's not usually a problem.

I do /not/ run sid on my secondary systems, because while I don't mind
having to do a bit more work to keep my primary system up-to-date, I do
mind having to repeat that for other systems. So these usually run
stable or testing, depending on the case. My previous laptop was a
powerbook, so I still occasionally use it for some powerpc testing.
However, building packages on that machine takes more effort, because
it's running testing; I feel that using chroots, either through pbuilder
or directly, or doing things like virtual machines, is quite a burden,
and that it interferes with my workflow. When using one of my secondary
machines, I'm therefore usually not as productive as when using my
primary one.

I guess what I'm trying to say is that while I understand the motivation
of many developers to run testing or stable on their machine, running
sid instead does have some important advantages for Debian Developers,
while the disadvantages are not as serious as they would seem at first
sight.

Of course, this all depends on how much time you're willing to put into
building/testing packages on the one hand, and maintaining your primary
system on the other. To me, the balance is in favour of running sid, but
of course YMMV.

--
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
http://www.schneier.com/blog/archives/2009/01/biometrics.html
 
Old 03-30-2010, 12:56 PM
Holger Levsen
 
Default Best practices for development workstations

Hi John,

On Dienstag, 30. März 2010, John Goerzen wrote:
> 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.

squid!

(Or any other normal http proxy. I don't recommend any apt-proxy solution...)


cheers,
Holger (running lenny + custom backports on his laptop (ie I'm using xorg
from experimental but provided in a local stable repo), plus chroots
as well virtual machines with virtualbox. Building is always done in
pbuilder (or an extra, clean lenny chroot).
 
Old 03-30-2010, 01:07 PM
Marco Túlio Gontijo e Silva
 
Default Best practices for development workstations

Hi Holger.

Excerpts from Holger Levsen's message of Ter Mar 30 09:56:34 -0300 2010:
(...)
> On Dienstag, 30. März 2010, John Goerzen wrote:
> > 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.
>
> squid!
>
> (Or any other normal http proxy. I don't recommend any apt-proxy solution...)

Can you explain why?

Thanks in advance.
(...)
--
marcot
http://wiki.debian.org/MarcoSilva


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1269954437-sup-5625@zezinho">http://lists.debian.org/1269954437-sup-5625@zezinho
 
Old 03-30-2010, 01:31 PM
John Goerzen
 
Default Best practices for development workstations

Paul Wise wrote:
>> So I am concerned about this approach for security reasons as well.
>
> Could you detail your concerns here?

That was a braino. I meant to say *performance* reasons.

-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BB1FD3D.6090003@complete.org">http://lists.debian.org/4BB1FD3D.6090003@complete.org
 
Old 03-30-2010, 03:23 PM
John Goerzen
 
Default Best practices for development workstations

On Mon, Mar 29, 2010 at 05:43:06PM -0700, Russ Allbery wrote:
> John Goerzen <jgoerzen@complete.org> writes:
> 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.

One other potential problem with having my build environment be the
same as my workstation: I sometimes have non-Debian packages installed
(MythTV, nvidia drivers, other stuff I'm working on, etc.) that I
occasionally worry could cause dependency issues. To date I have been
careful with where I build things, and haven't yet had that problem.
But there is something of a conflict between "work environment" and
"clean development environment". Of course, once I go to having
development in its own environment, there is no longer much call for
running sid directly on the thing -- and listing but deprioritizing
sid could be useful for when I have to test things from sid.

-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100330152323.GA27700@excelii.com">http://lists.debian.org/20100330152323.GA27700@excelii.com
 
Old 03-30-2010, 03:24 PM
John Goerzen
 
Default Best practices for development workstations

On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote:
> 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.

I'm having a bit of trouble visualizing how that works; can you spell
out your apt settings?

-- John


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100330152431.GB27700@excelii.com">http://lists.debian.org/20100330152431.GB27700@excelii.com
 
Old 03-30-2010, 05:47 PM
Russ Allbery
 
Default Best practices for development workstations

John Goerzen <jgoerzen@complete.org> writes:

> One other potential problem with having my build environment be the same
> as my workstation: I sometimes have non-Debian packages installed
> (MythTV, nvidia drivers, other stuff I'm working on, etc.) that I
> occasionally worry could cause dependency issues. To date I have been
> careful with where I build things, and haven't yet had that problem.
> But there is something of a conflict between "work environment" and
> "clean development environment". Of course, once I go to having
> development in its own environment, there is no longer much call for
> running sid directly on the thing -- and listing but deprioritizing sid
> could be useful for when I have to test things from sid.

I always do all package builds inside pbuilder unless for some reason I
have to look at the results of a partial build, which is how I get around
that problem.

--
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: 87eij1ln1b.fsf@windlord.stanford.edu">http://lists.debian.org/87eij1ln1b.fsf@windlord.stanford.edu
 
Old 03-31-2010, 06:44 AM
Paul Wise
 
Default Best practices for development workstations

On Tue, Mar 30, 2010 at 11:24 PM, John Goerzen <jgoerzen@complete.org> wrote:
> On Tue, Mar 30, 2010 at 09:02:59AM +0800, Paul Wise wrote:
>> 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.
>
> I'm having a bit of trouble visualizing how that works; can you spell
> out your apt settings?

Something like this (not my exact settings):

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Package: *
Pin: release a=experimental
Pin-Priority: 550

The priorities need to be > 500 and < 1000.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: q2we13a36b31003302344wc60b0572u507fdd57e86f9fc5@ma il.gmail.com">http://lists.debian.org/q2we13a36b31003302344wc60b0572u507fdd57e86f9fc5@ma il.gmail.com
 

Thread Tools




All times are GMT. The time now is 04:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org