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

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

> > 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: