Re: Bug#88029: Package which uses jam (instead make)
On Mon, Oct 20, 2003 at 12:35:04AM +0200, Josip Rodin wrote: On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: I've yet to see a technical argument for allowing debian/rules to be a non-makefile. I've yet to see a technical argument for disallowing debian/rules from being a non-makefile. (itinerant policy-editor hat on) Me neither. -- G. Branden Robinson|Humor is a rubber sword - it allows Debian GNU/Linux |you to make a point without drawing [EMAIL PROTECTED] |blood. http://people.debian.org/~branden/ |-- Mary Hirsch signature.asc Description: Digital signature
Re: Bug#88029: Package which uses jam (instead make)
On Tue, 21 Oct 2003 14:26:45 -0500, Branden Robinson [EMAIL PROTECTED] said: On Mon, Oct 20, 2003 at 12:35:04AM +0200, Josip Rodin wrote: On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: I've yet to see a technical argument for allowing debian/rules to be a non-makefile. I've yet to see a technical argument for disallowing debian/rules from being a non-makefile. (itinerant policy-editor hat on) Me neither. I have made a few (including ./debian/rules in an superset debugging makefile, passing variables in MAKEFLAGS, using -j, -n, -p and other make arguments to arrive at similar invocations, using VPATH's et all to temporarily change include paths). In the case of a standard, however, Why not is not an adequate reason for change. Demonstrate a use case that can't be solved using Makefiles, and we'll see about changing the published interface. manoj -- You will be dead within a year. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#88029: Package which uses jam (instead make)
On Tue, Oct 21, 2003 at 05:13:14PM -0500, Manoj Srivastava wrote: I have made a few (including ./debian/rules in an superset debugging makefile, passing variables in MAKEFLAGS, using -j, -n, -p and other make arguments to arrive at similar invocations, using VPATH's et all to temporarily change include paths). None of them are relevant to policy, though. Or at least not any more relevant than any other feature of other interpreters that you dismissed under the why not category... -- 2. That which causes joy or happiness.
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 11:20:33AM +0200, Josip Rodin wrote: this-and-that function of Make (so far I remember only two of those, when the DEB_BUILD_OPTIONS env. variable was added and when testing for existence of build-arch was added). ... which was a fiasco. Doogie finally implemented the proposal and revert it dpkg (1.10.15) unstable; urgency=low * Back out debian/rules build-arch detection. It is *not* possible *at all* to detect available targets in a rules file. Period. -- Adam Heath [EMAIL PROTECTED] Fri, 19 Sep 2003 20:02:19 -0500 The rationale are not available to me, but I trust him since he really tried. At this point I see only two alternative: 1) use dependencies build: build-arch binary-indep: build-indep This is not good to run build-indep as root, but only the maintainer run binary-indep, and there is no need to change dpkg-buildpackage. 2) Set a make variable BUILD and do ifdef BUILD build: $(BUILD) else build: build-arch build-indep endif This require dpkg-buildpackage to call debian/rules with BUILD=build-arch or BUILD=build-indep accordingly. Of course, variants using environment variables exist. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 12:18:51PM +0200, Bill Allombert wrote: this-and-that function of Make (so far I remember only two of those, when the DEB_BUILD_OPTIONS env. variable was added and when testing for existence of build-arch was added). ... which was a fiasco. Doogie finally implemented the proposal and revert it dpkg (1.10.15) unstable; urgency=low * Back out debian/rules build-arch detection. It is *not* possible *at all* to detect available targets in a rules file. Period. -- Adam Heath [EMAIL PROTECTED] Fri, 19 Sep 2003 20:02:19 -0500 The rationale are not available to me, but I trust him since he really tried. I'd be interested to see doogie's rationale, but it's amusing enough as it stands, because the policy still says: If one or both of the targets `build-arch' and `build-indep' are not provided, then invoking `debian/rules' with one of the not-provided targets as arguments should produce a exit status code of 2. Usually this is provided automatically by make if the target is missing. ...thereby, in its trend of hinting at Make-specific stuff, going against the judgement of not one but two dpkg maintainers. -- 2. That which causes joy or happiness.
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 01:20:26PM +0200, Josip Rodin wrote: I'd be interested to see doogie's rationale, but it's amusing enough as it stands, because the policy still says: If one or both of the targets `build-arch' and `build-indep' are not provided, then invoking `debian/rules' with one of the not-provided targets as arguments should produce a exit status code of 2. Usually this is provided automatically by make if the target is missing. I believe something among the line of Not-provided targets as arguments should produce a exit status code of 2, but the converse is not true, therefore we cannot discriminate between unprovided targets and targets that lead to an error condition. Independently of the `Manoj vs Wichert' match, I would be interested at fixing the build-arch issue at last. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 04:20 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote: But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! We share an enthusiasm for overloaded phrases, I see :) but a small verbal blunder doesn't invalidate the issue at hand. -- 2. That which causes joy or happiness.
Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 13:03 (CDT), Josip Rodin [EMAIL PROTECTED] wrote: On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote: But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! We share an enthusiasm for overloaded phrases, I see :) but a small verbal blunder doesn't invalidate the issue at hand. No, it doesn't, but it doesn't validate it either. I've yet to see a technical argument for allowing debian/rules to be a non-makefile. If you really want to write the script in a different format, it's trivial to meet the letter of Policy: #!/usr/bin/make -f % : debian/my_rules.py $@ That I've never seen such done (in my admittedly limited and random selection of packages to build by hand at various times) suggests that there's not much practical demand. Whenever it's come up, it seems to be someone trying to prove a point, rather than a technical need. Perhaps those who think alternative debian/rules should be allowed should implement the above, and see what breaks and what complaints it generates. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: I've yet to see a technical argument for allowing debian/rules to be a non-makefile. I've yet to see a technical argument for disallowing debian/rules from being a non-makefile. See, those two statements make the same amount of sense. Anyone can throw in gobs of make features that are handy, and also gobs of other interpreters' features that are handy as well. That doesn't make any one of them technical arguments for either. If you really want to write the script in a different format, it's trivial to meet the letter of Policy: And it's also trivial to change the letter of Policy, too. Contrary to what some may have said, replacing the crude must rule will not cause anything to happen other than fixing a spurious requirement that exists in the documentation only. No, new maintainers won't suddenly start shipping precompiled a.out debian/rules files. They probably won't start using vertical Perl either. In fact the most likely result is that not one thing will change, except that a tiny fraction of packages will no longer be in violation of policy. That I've never seen such done (in my admittedly limited and random selection of packages to build by hand at various times) suggests that there's not much practical demand. Whenever it's come up, it seems to be someone trying to prove a point, rather than a technical need. I have had packages the rules file of which is not a makefile for years now. You didn't notice them, did you? That's probably because they (*gasp*!) work. And none of those purported NMUers ever complained about them either. Arguably that's because of other favourable circumstances, but nevertheless. The interface to the rules file is defined well enough, there's absolutely nothing wrong with having other things than /usr/bin/make abide by the same rules. -- 2. That which causes joy or happiness.
Bug#88029: Package which uses jam (instead make)
On Sat, 18 Oct 2003 15:02:10 +0200, Josip Rodin [EMAIL PROTECTED] said: 88029 yeah well. That is not all the dfiscussion there was on it. In March 2001, we had more than those comments on it: == If people really think that calling scripts from Makefiles is hard, should they really be maintaining Debian packages? So far, the arguments I have heard for removing this restrictions have been a) This new mechanism is so cool b) Makefiles can be really hard to write!! c) Why not? I guess my objection to this reduction of standardization is that there should be some inertia in policy, and that we need to see some stronger technical reasons to break the following practices: i) make -n -p -f ./debian/rules ii) in ./makefile: include ./debian/rules change targets and or rules, and spit out some things set in ./debian/rules (I actually did this for debugging a rules file) Yes, pretty arcane; but I contend that this argument is no weaker than any I have seen in support of this proposal. Wichert I'll make this a proposal then: Wichert As such I propose that the statement that debian/rules has be to a Wichert makefile be removed. I think I must object to this, on the grounds that we are now changing an published interface to the package building process. Indeed, I have used makefiles that include ./debian/rules and derive targets and tweak the make rules in the debian/rules process (security related experiments), and I would strongly object to the mechanisms being yanked out from under me. == I still think that what we have now is a long established interface to the build system; saying that the ./debian/rules file is a Makefile is a short hand for describing an extended version of the interface defined in Section 6: Software development Utilities Option of ISO/IEC 9945-2, ANSI/IEEE Std 1003.2, Infornation technology - Portable Operating System Interface (POSIX) -- Part 2: Sheel and Utilities. Specifically, section 6.2 make -- Maintain, update, and regenrate groups of programs. The extentions include GNU Make extrenstions, and requirements for certain targets to exist. A tacit part of the interface are how debugging works, how paths can be added to the build environment, how variables are set up and modified. Pretending that this is not an interface that we have now depended upon for years is hiding from the facts manoj -- What is wanted is not the will to believe, but the will to find out, which is the exact opposite. Bertrand Russell, _Sceptical_Essays_, 1928 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
