On Sun, May 10 2009, Steve Langasek wrote:
> On Mon, May 04, 2009 at 07:35:18AM +0200, Guillem Jover wrote:
>> * We can set the architecture and default flags (from policy) on the
>> makefile to be included, and packagers will be able to do the change
>> and fix any possible problems (progressive opt-in), but once it's
>> included by all packages, then we can do system-wide default changes
>> in the same we change toolchains (mass rebuild, bug filing, change
>> when bug count goes down). The makefile has the advantage that the
>> distro default can be temporarily changed for the mass build w/o
>> needing to totally override the build flags.
>
> 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.
> 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)
> 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.
> 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.
manoj
--
Living your life is a task so difficult, it has never been attempted
before.
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-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
