Re: Environment variables, debian/rules and dpkg-buildpackage
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. It's *bad* because using 'include' semantics for config
files is Worst Practice.
> > 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.
> > 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.
> > 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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: