In 2/17/06, Jonathan Niehof <[EMAIL PROTECTED]> 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
