[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Environment variables, debian/rules and dpkg-buildpackage

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.

Remember, UNIX spelled backwards is XINU. Mt.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: