Re: Maintaining personal backports
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
Reply to: