On Tue, May 12 2009, Steve Langasek wrote: > On Mon, May 11, 2009 at 10:01:14AM -0700, Russ Allbery wrote: >> If they're built by the program, then anyone who wants to properly build >> the software, even if they don't want to go all the way to the package, >> will need to use the program, since people will write debian/rules such >> that it assumes the program is in use. They'll assume default CFLAGS >> are set and so forth. > >> I don't think this is the right direction to go, but I'm not going to >> stomp off in a huff if we go that direction or anything. :) But I do >> want to be sure that we're all clear on what we're saying if we do take >> that approach and make dpkg-buildpackage the only supported way to build >> packages. I think it's likely that if we go that route, with it >> providing the defaults, we'll find over time that some packages will >> either not build or will mis-build with debian/rules build and no one >> will notice or be particularly interested in fixing it. > > That's a fair point, and if preserving the behavior of debian/rules as a > standalone is important to others, then I'm happy for us to find a solution > that meets this requirement *as long as* it also avoids the pain of letting > mandated "config" files arbitrarily modify the behavior of debian/rules.
I am not sure I understand this. In effect, using helper packages can allow arbitrary programs to change the build behaviour of the package, but we heartily recommend using the helper packages. But that is different you say, we do not expect debhelper to change incompatibly without changing compat levels, we trust joey hess to never do that. (I do too). But this also implies that you do not trust dpkg maintainers to not put in things in the configuration files without due delibration, and that they will not actually set up a mechanism somewhat like COMPAT_VERSION (very easy to do in make snippets, BTW). I think we ought to trust the dpkg folks. The other use case is the site admin building packages for themselves, and the buildd maintainer, to set up the environment for their build daemon. In other mails, you have argued that the only thing you are worried about is build daemons, in that case, there are scads of things that a build daemon admin can do that changes how packages are built (versions of build essential packages, stuff related to compiling in /etc, ld.so being just one) -- so we do implicitly trust the build daemon maintainers to do the right thing. So, the only places we distrust people is either the maintainer for not setting their site config right, and uploading. But if you distrust the maintainer, you might as well give it up, or set up a process to require but discard .debs created by ordinary mere mortal DD's, and let only the works of those on high (the buildd folks) to go into Debian. A losing battle, I would say. The other person you are so worried about braeking things is the end user, who might muck up their site config, and thus build bad packages. That the end user building packages for their own may wreak greater havoc with vim is overlooked, neh? What is this distrust of the configuration files all about, then? I find it strange, and I think it stems from a very Cathedral like approach of not trusting the end users to even be able to manage site config files flies in the face of the bazaar; we allow for free software adherents and our users to bui9ld packages, and let them tinker and make mistakes. The supposed control over "people would not be able to afect how my package builds" is already a mirage. A buildd configuration is already beyond most peoples control. A hacked debhelper is also beyond your control. One of the major shortcomings of the way we build things, and that Gentoo has a serious advantage, is the so called build flags -- with this include file approach, we can come close to the build flags approach, and let specialized build daemons be set up with site config different from the norm to build specialized binary archives. Being tied to tradition does not help us here. manoj -- Remember, UNIX spelled backwards is XINU. Mt. Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org