Re: Build/test environment
In 2/17/06, Jonathan Niehof <jtniehof@gmail.com> wrote:
> 1) Since updated packages go into unstable, presumably they should be
> tested in an unstable environment. But they also want to percolate
> into testing, so they shouldn't break or be broken by testing. So I
> presume it's best to have an unstable test environment and a testing?
It depends on the kind of patch you are doing, but it's usually a good
idea to have both an "unstable" environment and a "testing"
environment so that you can test propagation of the fixes and so on.
Also, it might -sometimes- be necessary to see if a bug is present in
one version but not on the other.
> 2) My laptops are happily running sarge. My main desktop...well, it
> used to be hamm, but by now you might as well call it LFS. Sadly I
> have other things to do with my computers :) so I'd rather not have
> testing or unstable accidentally run roughshod over my
> filesystem--what's "the" (or "a") preferred way of setting up a test
> environment? New partition? UML? chroot with debootstrap?
I'd choose a chroot over the UML thing, because a chroot is much
simpler to administrate, and you don't have to do anything special to
have support for all your hardware. But that is a "taste" option, if
you are really skilled with UML, it might be ok.
If you have the disk space to have a new partition, that is of course
a very good choice. But if you don't you could have a chroot in a
loopback file and use it for testing. In my case, I have "etch" as my
desktop and "sid" in a chroot that is on a separate disk partition.
In the case that I want to test (or build) something specifically for
sarge, I have a chroot-loopback file for that.
> 3) When making and testing fixes, is the best way to bump the debian
> version number, treat the whole package as if one were doing a
> maintainer upload, then build and install the package? Or is there a
> "better" procedure I'm missing? (Obviously the final product is a
> patch to send the maintainer, not a package.)
I usually pretend I'm doing an NMU. That is, I add a new version
number to the changelog (with "dch -i"), and state there all the
things that I'm doing to the package. It helps later, when you want
to remember what things you did.
This might seem a bit lame, but we human beings tend to think that we
are going to remember certain things, and then we forget them; so it's
best to be prepared, and state clearly what you are doing, even if you
are sure that you won't forget.
Also, I suggest you read:
http://women.alioth.debian.org/wiki/index.php/English/AdvancedBuildingTips
It has some tips that you might not know, and that have proved to be
quite useful.
--
Besos,
Marga
Reply to: