On Wednesday 22 July 2009 09:18:11 Kumar Appaiah wrote: > 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 BTW, I almost forgot. You may want to take a look at this: http://www.emdebian.org/ There is a lot of interesting ideas here about rebuilding packages for an embedded environment, and many of these ideas are useful for helping to make a customized distribution, regardless of whether the target is embedded or not. -- Thanks: Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.