Re: Environment variables, debian/rules and dpkg-buildpackage
On Tue, May 12 2009, Steve Langasek wrote:
> On Sun, May 10, 2009 at 11:30:43PM -0500, Manoj Srivastava wrote:
>> > I'm really surprised to see this approach getting traction. To me,
>> > this seems like a significant, unprecedented departure from the kinds
>> > of interfaces we've mandated in Policy in the past (i.e., environment
>> > variables, executables and command-line options). While one build
>
>> I am happy to see this gain traction, really. And "We have not
>> done so in the past" is a very illogical criteria to judge the
>> technical merits of a proposal, I hope no one puts much weight on it.
>
> No, it's *surprising* because it's a departure from the mechanisms
> used in Policy in the past.
But novelty is often a characteristic of innovative solutions.
> It's *bad* because using 'include' semantics for config files is Worst
> Practice.
Sez You. I find it liberating, and far more flexible.
>
>> > helper or another may mandate Makefile includes, there's never been
>> > anything of the sort in Policy, and I don't think it's good to add
>> > such a thing now. I thought it was generally recognized that it's a
>> > Bad Idea to implement config files using your interpreter's 'include'
>> > functionality, but that's basically what we have here.
>
>> I find it a fine and flexible idea to implement configuration
>> files using include mechanisms, including Perl load
>> directives. Gives the end user full control (and yes, with full
>> control comes great responsibility, Peter Parker would say)
>
> Why is a user who wants that kind of "full control" running Debian
> instead of Slackware? I expect Debian to provide sane delineation between
> supported and unsupported changes to the system, not encourage rampant
> foot-shooting.
This seems to indicate more a failure of imagination on your
part. You do not get to specify what users might want to do, or not,
based on what you imagine they should be allowed to do.
>> > If there's any intention at all that Policy eventually mandate use of
>> > these Makefile includes, then at a minimum I think Policy needs to
>> > *very* tightly constrain what dpkg is allowed to put in those files,
>> > to avoid future incompatibilities.
>
>> I think what dpkg sets in the env variables is a fine start. And
>> policy should not be a stick to hit the dpkg developers on the head
>> with. I say we let an implementation blossom in the wild, see what
>> works, and then codif that in policy.
>
>> Policy is not the place to do design in.
>
> I said that tightly-constrained config files should be a condition of
> mandating such includes. If you're not going to specify a reasonable
> interface, then fine - it doesn't need to be in Policy.
The initial implementation is not going to be defined in policy,
no. Once a working solution exists, and has stabilized, we may
enshrine that in policy.
>> > But unfortunately, if we're going to support site files, we're in no
>> > position to enforce such requirements there; so packages are still
>> > subject to breakage from admins populating their site file with random
>> > settings (or syntax errors?).
>
>> Right. The admins can break package compilation, and then they
>> get to keep all the parts. I see no harm in this. We should get away
>> from the Cathedral mode of looking at our end users as morons who need
>> to have their hands held, and start trusting them to know what they do.
>
>> If a site want s to do things that Debian Power Up On High
>> consider to be The Wrong Thing, I think we should give the sites
>> enough rope.
>
> Right - I'll be sure to forward all the resulting bug reports to you,
> then.
So it is centralized control, or I get to deal with the bugs?
Heh. Sounds like Ubuntu.
manoj
--
Stenderup's Law: The sooner you fall behind, the more time you will have
to catch up.
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: