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? > While I think it's a good idea, making a proposal that would be acceptable won't be easy. One reason is that each USE flag would have to be well specified or defined so that its meaning is clear. The actual use of those USE flags would only be for those people who would be building their own distribution based from the debian sources. It would be unreasonable for debian to try and distribute binaries for different combinations of those flags (or even a small subset of commonly expected combinations). However, debian already does ship binaries with a common "USE combination", which is close to USE="this that +kitchen-sink" (at least mostly, some sources are split into multiple binaries that effectively use different USE flags). Things would have to be done in a way that discourages people who would build packages using USE flags that diverge from the official builds from reporting bugs against those packages, as it would be way too difficult to determine where the bug is, what caused it, etc. In many situations, not only would it be necessary to modify the rules file, but also the control file. On certain packages, it may even be required to modify some of the postint, preinst. On packages with *.install files in the debian/ directory, it may be difficult for the maintainer to know which files may or may not be present with respect to how it was configured or built, based on the USE flags. In some cases, entire packages would have to be removed from the control file, as the USE flags wouldn't allow them to be built. This can possibly cause problems further down in the package tree, where another package depends on the package that was removed. It's been taking me a while to think through this as I've been writing. In the meantime, I've seen that you've already received a response pointing to a thread on debian-devel. I've just skimmed through it, and it seems to be mainly concerned more with CFLAGS and such, rather than USE flags. Most of what I've been doing is related to this, as I have had no desire to change the way that the packages are related to one another, only in how they are built. I think that it's better to start along those lines, rather than try to propose a "USE flags" policy, due to my reasoning above. There is a very large difference between those two ideas. > Thanks. > > Kumar -- Thanks: Joseph Rawson
Attachment:
signature.asc
Description: This is a digitally signed message part.