On Wed, Jul 22, 2009 at 10:57:28AM -0500, Joseph Rawson wrote: > > 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).
Exactly. It is the kitchen sink and compiler flags which I want to attack with this proposal. > 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. One could claim that this might result in bug reports being filed, where users use packages which are built "unofficially". While I agree that this is a problem, people could just as well download the source, make changes, and build it and end up with unofficial packages, and file bugs much the same way. This, I believe, should not be the biggest detriment though, or so I feel, as I read through the rest of your mail. > 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. A simple example is a package which has a command line interface as well as a GTK+ based interface. By switching some options, if we make the GTK+ interface redundant, the install files will now be incorrect, and maybe the <pkg>-gtk binary package might not be built (or built empty) > 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. I agree. Let me look at the build option customization first, as that might be an easier thing to tackle. In this context, I've toyed around with apt-build, and even submitted a few patches. But my unhappiness with it is because it tries to work around the limitation in the build system with regard to compiler flags, and thus, may fail for corner cases. A more systematic approach to compiler flag customization would be welcome. I would like to discuss this further with you sometime, maybe off list first, then in debian-devel, maybe, since this is becoming off-topic for debian-user. Thanks for the fine arguments and comments. Kumar -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
