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-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
