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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
