On Wed, Jul 22, 2009 at 08:56:25AM -0500, Joseph Rawson wrote: > Using reprepro makes it easy to upload the new packages to an "experimental" > dist for testing, then call "reprepro -b /path/to/repos copysrc experimental > lenny-backports $srcname". I had to learn this the hard way, because > occasionally some backported packages don't work properly.
Thanks for the tip. I'll note it down for reference. > If you have a spare machine, or enough spare ram to run virtualbox, you may > want to take a look at cowpoke (in the devscripts package). Cowpoke will run > cowbuilder on a remote machine (or VM if you use virtualbox). Here you get > the benefit of having a build log saved for you, having lintian run on the > result (you may not care about this) and also having the .changes file signed > (you may not care about this either). True. But it's a personal machine, and only for a few packages. > On a related note, I've been spending the last week on rebuilding lenny > packages using alternative CFLAGS and -march options. I have a friend who's > running gentoo, and he keeps telling me that they have a better system for > building packages with the options the you select. I decided to try and make > my own quick, sloppy build system using multiple buildd's with cowpoke as an > example. I've had mixed results with some packages honoring those options > and other packages ignoring them. It's been a very interesting experiment. This interests me a lot. I have been thinking for a long time about the "Gentoo" way, and I've been thinking why it should be any different for Debian. Let me detail you on what my idea is, since you've pretty much been doing something similar. Suppose there is a Debian package, which uses configure and supports several options using the many --enable-<feature> flags, or, alternately, disables some in a similar manner. If you want a custom package, you would have to do apt-get source <pkg>, and manually edit the rules file to enable or disable the options, or change the CFLAGS or compiler options. Not too difficult, but it the method differs from package to package. Why not alter the rules file to provide default values, and alter itself according to the environment, or according to some settings in a file like Gentoo's /etc/mk.conf? To firm up my description, consider the case of mutt, or elinks. Say you don't need mutt's IMAP support or SMTP support, or elinks' 256 colour support. It's not too tough to get the source package, modify one or two lines, and build it. But what I am hoping for is something like USE="-smtp -imap" debuild or the like, and other options such as compiler flags can also be specified. This is much less kludgey, and is much automated, like Gentoo. Granted, this would require the modification of debian/rules files to be sensitive to the environment variables, but I was still hopeful that if we can formulate a standard to adhere to, we could propose this to some package maintainers for packages where it could make a difference (smaller executable sizes, faster/more optimized performance for number crunching etc.). Do you think this is a good idea? Thanks. Kumar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org