Re: Package which uses jam (instead make)
On Tue, 28 Oct 2003 16:40:03 -0600, Marcelo E Magallon [EMAIL PROTECTED] said: On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote: We just disallow some usage that has been explicitley stated to work. A gratuitous change, with no compelling use cases, or even a rationale beyond why not?, hopefully shall not be accepted. You keep on referencing to particular features of a specific implementation of make. Since I know you have a gazillion Unix years under your belt, that comes as a surprise to me. For example, you keep talking about including makefiles, but that happens to be a GNU make feature. The way VPATH works is also GNU make specific. The way -n works is specific to GNU make, too. If you want to tie debian/rules to GNU make, then modify policy to say so: a GNU Makefile. We are talking about Debian policy , are we not? Isn't the only make in Debian one with these features? Arguments regarding the nature of Debian's /usr/bin/make are not strong enough, not as a definition for an interface. Umm, they could be, in the context of Debian, just as dpkg behaviour serves as an interface to the packaging system. However, I'll be happy with the definition of Make as provided by POSIX as our interface spec. Policy says: This file must be an executable makefile, and contains the package-specific recipes for compiling the package and building binary package(s) from the source. excutable makefile, ok, this is the point of contempt. As defined by POSIX, if you wish to be pedantic. It must start with the line `#!/usr/bin/make -f', so that it can be invoked by saying its name rather than invoking `make' explicitly. That's just a corollary of the first part. Since an interactive `debian/rules' script makes it impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all _required targets_ MUST be non-interactive. At a minimum, required targets are the ones called by `dpkg-buildpackage', namely, _clean_, _binary_, _binary-arch_, _binary-indep_, and _build_. It also follows that any target that these targets depend on must also be non-interactive. *that* is an interface definition. No more than what POSIX specs say a Makefile is. The POSIX specs are far more complete, as they define all the variables make pays attention to, and special targets, and all. The architectures we build on and build for are determined by `make' variables using the utility `dpkg-architecture'. You can determine the Debian architecture and the GNU style architecture specification string for the build machine (the machine type we are building on) as well as for the host machine (the machine type we are building for). Here is a list of supported `make' variables: * `DEB_*_ARCH' (the Debian architecture) * `DEB_*_GNU_TYPE' (the GNU style architecture specification string) * `DEB_*_GNU_CPU' (the CPU part of `DEB_*_GNU_TYPE') * `DEB_*_GNU_SYSTEM' (the System part of `DEB_*_GNU_TYPE') where `*' is either `BUILD' for specification of the build machine or `HOST' for specification of the host machine. And *that* is also an interface definition. Calling these make variables is just bad wording, these are passed via the environment. The fact that GNU make turns these into make variables is not important. MAKEFLAGS is a defined interface into make, BTW. manoj -- The Ruffed Pandanga of Borneo and Rotherham spreads out his feathers in his courtship dance and imitates Winston Churchill and Tommy Cooper on one leg. The padanga is dying out because the female padanga doesn't take it too seriously. Mike Harding, The Armchair Anarchist's Almanac 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: Package which uses jam (instead make)
On Wed, Oct 29, 2003 at 04:04:35AM +0100, Henning Makholm wrote: Scripsit Marcelo E. Magallon [EMAIL PROTECTED] excutable makefile, ok, this is the point of contempt. If we're actually regarding each other's views with contempt, then there's not much point in continuing the discussion, I think. Oh, come on. It's obvious from context that he meant contention, and misspoke. Not all of us on these lists are native English speakers, but that doesn't excuse deliberate misconstrual of other people's words. -- G. Branden Robinson| You live and learn. Debian GNU/Linux | Or you don't live long. [EMAIL PROTECTED] | -- Robert Heinlein http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: Package which uses jam (instead make)
On Wed, Oct 29, 2003 at 04:04:35AM +0100, Henning Makholm wrote: debian/rules should be portable enough to work with any implementation of make [1]. That's the interface. If I have an implmentation that I know supports include files, I should be able to ask *my* implementation of make to include *somebody else's* debian/rules and expect it to work. You inferred that meaning yourself, it's not a universal fact. I for one don't see any reason why the Policy should mandate that feature, or any other feature not already stated in the manual (or proposed, of course). In fact, doing this would be the type of intrusive change that the conservatives among us would actually have reason to object to, unlike the change described in #88029. -- 2. That which causes joy or happiness.
Re: Package which uses jam (instead make)
On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote: We just disallow some usage that has been explicitley stated to work. A gratuitous change, with no compelling use cases, or even a rationale beyond why not?, hopefully shall not be accepted. You keep on referencing to particular features of a specific implementation of make. Since I know you have a gazillion Unix years under your belt, that comes as a surprise to me. For example, you keep talking about including makefiles, but that happens to be a GNU make feature. The way VPATH works is also GNU make specific. The way -n works is specific to GNU make, too. If you want to tie debian/rules to GNU make, then modify policy to say so: a GNU Makefile. Arguments regarding the nature of Debian's /usr/bin/make are not strong enough, not as a definition for an interface. Policy says: This file must be an executable makefile, and contains the package-specific recipes for compiling the package and building binary package(s) from the source. excutable makefile, ok, this is the point of contempt. It must start with the line `#!/usr/bin/make -f', so that it can be invoked by saying its name rather than invoking `make' explicitly. That's just a corollary of the first part. Since an interactive `debian/rules' script makes it impossible to auto-compile that package and also makes it hard for other people to reproduce the same binary package, all _required targets_ MUST be non-interactive. At a minimum, required targets are the ones called by `dpkg-buildpackage', namely, _clean_, _binary_, _binary-arch_, _binary-indep_, and _build_. It also follows that any target that these targets depend on must also be non-interactive. *that* is an interface definition. [Policy goes on and defines what these targets do] Additional targets may exist in `debian/rules', either as published or undocumented interfaces or for the package's internal use. Not an interface. The architectures we build on and build for are determined by `make' variables using the utility `dpkg-architecture'. You can determine the Debian architecture and the GNU style architecture specification string for the build machine (the machine type we are building on) as well as for the host machine (the machine type we are building for). Here is a list of supported `make' variables: * `DEB_*_ARCH' (the Debian architecture) * `DEB_*_GNU_TYPE' (the GNU style architecture specification string) * `DEB_*_GNU_CPU' (the CPU part of `DEB_*_GNU_TYPE') * `DEB_*_GNU_SYSTEM' (the System part of `DEB_*_GNU_TYPE') where `*' is either `BUILD' for specification of the build machine or `HOST' for specification of the host machine. And *that* is also an interface definition. Calling these make variables is just bad wording, these are passed via the environment. The fact that GNU make turns these into make variables is not important. Marcelo
Re: Package which uses jam (instead make)
Scripsit Marcelo E. Magallon [EMAIL PROTECTED] If you want to tie debian/rules to GNU make, then modify policy to say so: a GNU Makefile. Arguments regarding the nature of Debian's /usr/bin/make are not strong enough, not as a definition for an interface. debian/rules should be portable enough to work with any implementation of make [1]. That's the interface. If I have an implmentation that I know supports include files, I should be able to ask *my* implementation of make to include *somebody else's* debian/rules and expect it to work. [1] Perhaps. The dh_make templates for debian/rules actually do contain gnuisms, so this is not true in practise. excutable makefile, ok, this is the point of contempt. If we're actually regarding each other's views with contempt, then there's not much point in continuing the discussion, I think. And *that* is also an interface definition. Calling these make variables is just bad wording, these are passed via the environment. Actually, makefile variables can also be passed on the command line, at least with the implementations of make that I'm familiar with. The fact that GNU make turns these into make variables is not important. It *is* a part of the interface that I can compile my own patched version of make that hardcodes one or more of these variables, and expect things to work when I ask it to interpret debian/rules. -- Henning Makholm Det er jo svært at vide noget når man ikke ved det, ikke?
Re: Package which uses jam (instead make)
On Wed, Oct 22, 2003 at 01:37:36AM +0200, Josip Rodin wrote: On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote: If you do not stick to the documented interfaces, you lose the ability in my eyes to express outrage when the interfaces you use change. Except one important difference -- in this case, NOTHING CHANGES in the interface if the policy proposal is accepted. We just disallow some usage that has been explicitley stated to work. No. How did you come to that conclusion? This is another time you're giving the impression of don't take away my makefile rules files!. Well, maybe there's some Grinch out there who wants to steal them away from you, but I assure you that my intentions are not to do that. :) I don't Manoj is accusing you of trying to force him to make his rules files not be Makefiles. He's accusing you of trying to let other people make *their* rules files non-Makefiles, which is objectionable to him, because he likes to play with MAKEFLAGS and VPATH. I disagree with him, however, since Policy does not forbid, even implicitly, a developer from sabotaging the values of these variables in the rules file. In my opinion, Manoj's rationale for not tolerating alternative implementations of make is not grounded on any documented interface, but rather his knowledge of what's going on *behind* the interface. Good programmers know not to take such things for granted. Unless Manoj can come up with a different argument that I find persuasive, I would continue to support a proposal to loosen the definition of a debian/rules file in this respect. -- G. Branden Robinson|Lowery's Law: Debian GNU/Linux |If it jams -- force it. If it [EMAIL PROTECTED] |breaks, it needed replacing anyway. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
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: Package which uses jam (instead make)
On Tue, 21 Oct 2003 17:00:17 +0200, Josip Rodin [EMAIL PROTECTED] said: On Sat, Oct 18, 2003 at 07:55:00PM -0500, John Goerzen wrote: If you do not stick to the documented interfaces, you lose the ability in my eyes to express outrage when the interfaces you use change. Except one important difference -- in this case, NOTHING CHANGES in the interface if the policy proposal is accepted. We just disallow some usage that has been explicitley stated to work. A gratuitous change, with no compelling use cases, or even a rationale beyond why not?, hopefully shall not be accepted. manoj -- Committee, n.: A group of men who individually can do nothing but as a group decide that nothing can be done. Fred Allen 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: Package which uses jam (instead make)
On Tue, 21 Oct 2003 16:58:55 +0200, Josip Rodin [EMAIL PROTECTED] said: On Mon, Oct 20, 2003 at 09:54:13PM -0500, Manoj Srivastava wrote: It is documented to be a Makefile. That _is_ the interface definition. Actually, we don't know that. We don't? The original documentation did not explicitely say that all rules files absolutely need to be makefiles, but we warped it to mean that later. I do not think it is relevant what the original intent was, or how it got into the standard (I am toal there are hoary tales associated with tne C++ standard); the fact is that this has been accepted practice as long as there has been a rules file, and has been documented as being a Makefile for some time now. Given the lack of a compelling technical reason to change, standards documents should not change. And the technical policy is a standards document, as far as the project is concerned. manoj -- I don't think we should punish the criminal [a rapist] by killing his child. Dr. John Wilke, President, National Right to Life Committee, Search for Common Ground, taped for television 4/89, as quoted in The Far Right, Speaking For Themselves, a Planned Parenthood pamphlet 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, 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: Package which uses jam (instead make)
On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote: If you do not stick to the documented interfaces, you lose the ability in my eyes to express outrage when the interfaces you use change. Except one important difference -- in this case, NOTHING CHANGES in the interface if the policy proposal is accepted. We just disallow some usage that has been explicitley stated to work. No. How did you come to that conclusion? This is another time you're giving the impression of don't take away my makefile rules files!. Well, maybe there's some Grinch out there who wants to steal them away from you, but I assure you that my intentions are not to do that. :) -- 2. That which causes joy or happiness.
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: Package which uses jam (instead make)
On Tue, Oct 21, 2003 at 05:01:21PM -0500, Manoj Srivastava wrote: the fact is that this has been accepted practice as long as there has been a rules file, and has been documented as being a Makefile for some time now. Given the lack of a compelling technical reason to change, standards documents should not change. Saw that one coming a mile away. (End of [EMAIL PROTECTED]) -- 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
