On Thu, Dec 06, 2007, Manoj Srivastava wrote: > >> d) stands in the way of technical proposals like passing information > >> to the build system on the command line > >> e) prevents people from relying on make semantics for builds. > > > The two above points are the same argument. The only proposal I know > > it stands on the way of is the one to list implemented targets with a > > special make invocation which seemed flaky anyway. > > [...] unimportant, if indeed it works.
I got the feeling it was flaky from the criticism I read on debian-policy@ and that it couldn't work for all Makefiles; for example someone proposed to "make -f debian/rules -pn | grep '^build-arch:'" but this obviously wont fly if this is implemented as a "build-%:" rule. In fact I have packages with build-% rules, and certainly they shouldn't match such checks as they don't implement build-arch. > > Not constraining the interface if we don't need to? There's a huge > > difference in possibilities between "any script" and "a Makefile". > I do not agree that there is no need to so constrain it. I have > made the argumen in #88111; please read it. I did; I don't think you can reliably include a Makefile written by somebody else with the only constraints of the current policy. It would require tons of policies to make this reliable. Process interfaces draw a much clearer line. I'm sure that as the make maintainer you do know how complex a Makefile can get. It seems much more easy to usefully standardize the behavior of a process (flags / arguments, exit code, env vars, external deps, current working directory: sounds sane) than of a Makefile. > > Yes, we can do it in other ways, such as defining which flags or env > > vars have to be honored, or which files have to be read. > Right. We can re-invent the wheel on our own, in a classic > example of NIH, for absolutely no reason -- apart from not liking a > solution that is already in place. I disagree that it's for no reason; some proposed uses aren't safe and we have better replacement proposals (such as using a control field or an env var). We already proved the use over many more years of env vars passed to debian/rules, arguments passed on the command-line, or of data in debian/control. Proposing to use the new channels such as makefile inclusion or querying for the implemented rules is looking for trouble and discourages other options. I'm not under the impression that you're still open-minded on the topic, and since you're one of our beloved policy maintainers, and make maintainer, I don't think it's worth our time to repeat the arguments which have already been made. I simply want it recorded that some people do think it's a bad idea to require debian/rules to be a Makefile; I hope it will discourages people to rely on this. -- Loïc Minier
