Bug#88111: policy should not dictate implementation details
On Sat, Mar 03, 2001 at 12:38:33PM +1000, Anthony Towns wrote: Wichert wrote: I highly object to complicant the interface to debian/rules. Anthony wrote: But, uh, isn't that what you're doing? No, because allowing non-makefile rules files wouldn't require any changes to the interface (i.e. the ways of invoking the file). Consider people actually trying to *use* the debian/rules though. Manoj has posted some examples that won't work anymore. make -j0 clean build binary might be another, for example. I was referring to the ways of invoking the file that were mandated/mentioned. Besides, such a make flag can still be passed on to the sub-makes (if any) by modifying the $MAKE variable, no? -- Digital Electronic Being Intended for Assassination and Nullification
Bug#88111: policy should not dictate implementation details
[EMAIL PROTECTED] (Wichert Akkerman) wrote on 01.03.01 in [EMAIL PROTECTED]: I'll make this a proposal then: Section 5.2 of policy currently dictates that debian/rules has to be a makefile. While this is good practice, the only thing that is essential is that it is an executable that will respond to the build, clean, binary, binary-arch and binary-indep targets. As such I propose that the statement that debian/rules has be to a makefile be removed. I formally object to this proposal, on the grounds that it is a completely useless complication of the process. There's nothing you can do with a non-makefile executable that you can't just as easily do by invoking that executable from the makefile, and this other executable will never be able to emulate all of make's behaviour. In short, it buys us exactly nothing except for trouble. MfG Kai
Re: Bug#88111: policy should not dictate implementation details
Hi, Wichert == Wichert Akkerman [EMAIL PROTECTED] writes: Wichert But Manoj said he would remove the non-policy bits from it, and this Wichert would clearly fall in that category imho. I disagree. 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. manoj -- A mind is a terrible thing to have leaking out your ears. The League of Sadistic Telepaths 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
Bug#88111: policy should not dictate implementation details
On Thu, Mar 01, 2001 at 05:20:47PM +0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise This has *never* been required, was never documented anywhere, and is not needed at all. See bug#72335 (accepted). It'll fall over badly if this behaviour is not honoured (which it is by make). Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#88111: policy should not dictate implementation details
On Thu, Mar 01, 2001 at 05:43:28PM +0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: Right. Give a policy diff which specifies *exactly* what interfaces are required of debian/rules. I'll make some other changes as well. I notice the current policy documented is poluted with things like scripting advise, which should be in a seperate document. Agreed (and I've already written to -policy about this about 2 weeks ago). Patch is attached. - sect1 - headingError trapping in makefiles/heading Agreed, as long as it goes somewhere. - sect1 - headingObsolete constructs and libraries/heading Ditto. p - This file must be an executable makefile, and contains the + This file must be an executable, and contains the package-specific recipes for compiling the package and building binary package(s) out of the source. /p p - It must start with the line tt#!/usr/bin/make -f/tt, - so that it can be invoked by saying its name rather than - invoking prgnmake/prgn explicitly. + The ttdebian/rules/tt takes a single argument, which is + the target we want to build. Success should be indicated + using the exitcode: an exitcode of 0 indicates success, + any other code indicates a failure. Simply not true. Read the source code for dpkg-buildpackage. I'm objecting to this until we specify the following (growing) minimal interface: debian/rules [variable=value ...] target [variable=value ...] exit: 0 if OK, non-0 otherwise debian/rules -q target exit: 2 if target cannot be built (doesn't exist), non-2 otherwise p - For some packages, notably ones where the same - source tree is compiled in different ways to produce - two binary packages, the prgnbuild/prgn target - does not make much sense. For these packages it is - good enough to provide two (or more) targets - (ttbuild-a/tt and ttbuild-b/tt or whatever) - for each of the ways of building the package, and a - prgnbuild/prgn target that does nothing. The - prgnbinary/prgn target will have to build the - package in each of the possible ways and make the - binary package out of each. - /p Not so obvious; we've already specified what the build target must do. - p - The prgnbuild/prgn target may need to run - prgnclean/prgn first - see below. - /p Agreed. - p - When a package has a configuration routine that - takes a long time, or when the makefiles are poorly - designed, or when prgnbuild/prgn needs to run - prgnclean/prgn first, it is a good idea to - tttouch build/tt when the build process is - complete. This will ensure that if ttdebian/rules - build/tt is run again it will not rebuild the - whole program. - /p Ditto. - tagttget-orig-source/tt (optional)/tag + p + The optional target are: + taglist + tagttget-orig-source/tt/tag item Good cosmetic change. Does anyone provide this target, incidentally? - p - This target is optional, but providing it if - possible is a good idea. - /p Agreed. p - The prgnbuild/prgn, prgnbinary/prgn and - prgnclean/prgn targets must be invoked with a current + ttdebian/rules/tt must be invoked with a current directory of the package's top-level directory. /p Perhaps better: debian/rules must assume that it is being invoked ... We're not actually invoking it in policy. - This is generated by the prgn822-date/prgn - program. + This can generated by the prgn822-date/prgn + program, or by using the -R option for date. Yes. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#88111: policy should not dictate implementation details
retitle [PROPOSAL] Optional build-arch and build-indep targets for debian/rules thanks Previously Julian Gilbey wrote: See bug#72335 (accepted). How can this be accepted if there is no record of a second in the BTS? There are a few `this is a good idea' remarks, but no official second (and no signed mail at all). Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
Previously Julian Gilbey wrote: Simply not true. Read the source code for dpkg-buildpackage. I'm objecting to this until we specify the following (growing) minimal interface: debian/rules [variable=value ...] target [variable=value ...] I highly object to complicant the interface to debian/rules. Environment variables work fine, and are *much* easier to handle, especially if we someday decide to replace debian/rules with something that is not a makefile. debian/rules -q target exit: 2 if target cannot be built (doesn't exist), non-2 otherwise I still completely fail to see why that -q is needed. I can't find any argumentation for introducint it. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
On Fri, Mar 02, 2001 at 11:48:49AM +0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: Simply not true. Read the source code for dpkg-buildpackage. I'm objecting to this until we specify the following (growing) minimal interface: debian/rules [variable=value ...] target [variable=value ...] I highly object to complicant the interface to debian/rules. But, uh, isn't that what you're doing? debian/rules has been a makefile forever, allowing it to be anything else doesn't buy anything practical, just a little geek value for useless packages like shoop. Something like ``debian/rules is usually an executable makefile with a #!/usr/bin/make -f line. It may be other things, but if so it's the maintainer's responsibility to ensure the rules file functions appropriately for autobuilding.'' for example. Cheers, aj, who is sure there're better things to be spending time on than this -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgp2Ha2Esy5GP.pgp Description: PGP signature
Bug#88111: policy should not dictate implementation details
On Fri, Mar 02, 2001 at 11:48:49AM +0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: Simply not true. Read the source code for dpkg-buildpackage. I'm objecting to this until we specify the following (growing) minimal interface: debian/rules [variable=value ...] target [variable=value ...] I highly object to complicant the interface to debian/rules. Environment variables work fine, and are *much* easier to handle, especially if we someday decide to replace debian/rules with something that is not a makefile. Your proposed patch to dpkg-buildpackage will resolve that issue. debian/rules -q target exit: 2 if target cannot be built (doesn't exist), non-2 otherwise I still completely fail to see why that -q is needed. I can't find any argumentation for introducint it. Patch for dpkg-buildpackage once the build-arch/build-indep proposal goes into policy: if [ x$sourceonly = x ]; then -withecho debian/rules build $archlist +if [ $binaryonly = -B ] +then +debian/rules -q build-arch /dev/null 21 +if [ $? -eq 2 ] +then +withecho debian/rules build $archlist +else +withecho debian/rules build-arch $archlist +fi +fi withecho $rootcommand debian/rules $binarytarget $archlist fi Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#88111: policy should not dictate implementation details
Previously Anthony Towns wrote: But, uh, isn't that what you're doing? debian/rules has been a makefile forever, allowing it to be anything else doesn't buy anything practical, It buys us freedom and room to experiment and innovate. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
On Fri, Mar 02, 2001 at 11:46:39AM +0100, Wichert Akkerman wrote: retitle [PROPOSAL] Optional build-arch and build-indep targets for debian/rules thanks Previously Julian Gilbey wrote: See bug#72335 (accepted). How can this be accepted if there is no record of a second in the BTS? There are a few `this is a good idea' remarks, but no official second (and no signed mail at all). Roman and myself seconded it. But I'm willing to follow things to the letter, write a final proposal and go through the seconding process again. And feel free to comment. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London Debian GNU/Linux Developer, see http://people.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Bug#88111: policy should not dictate implementation details
On Fri, Mar 02, 2001 at 02:38:41PM +0100, Wichert Akkerman wrote: Previously Anthony Towns wrote: But, uh, isn't that what you're doing? debian/rules has been a makefile forever, allowing it to be anything else doesn't buy anything practical, It buys us freedom and room to experiment and innovate. So does leaving it as a makefile. (See Joey H's example from earlier in the thread) Cheers, aj, freedom to innovate indeed -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpwwqf4oDc99.pgp Description: PGP signature
Bug#88111: policy should not dictate implementation details
Julian wrote: debian/rules [variable=value ...] target [variable=value ...] Actually, it's this: debian/rules target [variable=value ...] At least, that's how dpkg-buildpackage does it, the target is always the first parameter. Wichert wrote: I highly object to complicant the interface to debian/rules. Anthony wrote: But, uh, isn't that what you're doing? No, because allowing non-makefile rules files wouldn't require any changes to the interface (i.e. the ways of invoking the file). It seems Wichert also wants to move the defining of $DEB_* variables to the environment; that's a separate issue. -- Digital Electronic Being Intended for Assassination and Nullification
Bug#88111: policy should not dictate implementation details
On Fri, Mar 02, 2001 at 06:18:31PM +0100, Josip Rodin wrote: Wichert wrote: I highly object to complicant the interface to debian/rules. Anthony wrote: But, uh, isn't that what you're doing? No, because allowing non-makefile rules files wouldn't require any changes to the interface (i.e. the ways of invoking the file). Consider people actually trying to *use* the debian/rules though. Manoj has posted some examples that won't work anymore. make -j0 clean build binary might be another, for example. It seems Wichert also wants to move the defining of $DEB_* variables to the environment; that's a separate issue. Not really. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpGKae73DGgE.pgp Description: PGP signature
Bug#88111: policy should not dictate implementation details
Package: debian-policy Previously Anthony Towns wrote: It'll have happened during Manoj's incorporation of the packaging-manual into policy. See 72949. You'll notice you seconded it... :) But Manoj said he would remove the non-policy bits from it, and this would clearly fall in that category imho. I'll make this a proposal then: Section 5.2 of policy currently dictates that debian/rules has to be a makefile. While this is good practice, the only thing that is essential is that it is an executable that will respond to the build, clean, binary, binary-arch and binary-indep targets. As such I propose that the statement that debian/rules has be to a makefile be removed. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
Previously Julian Gilbey wrote: debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise This has *never* been required, was never documented anywhere, and is not needed at all. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
On 20010301T155542+, Julian Gilbey wrote: In particular, the following should be minimally required: debian/rules required-target exit status: 0 if success, non-zero otherwise debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage. Once that is done, I think I'll be happy with the proposal. There is already another proposal about this. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T152221+0100, Wichert Akkerman wrote: I'll make this a proposal then: Section 5.2 of policy currently dictates that debian/rules has to be a makefile. While this is good practice, the only thing that is essential is that it is an executable that will respond to the build, clean, binary, binary-arch and binary-indep targets. That is false. Currently policy defines the interface of a debian/rules and even some of its behaviour by saying that it is a Makefile. If we decide to remove that requirement, we will need to specify its interface and behaviour another way. As such I propose that the statement that debian/rules has be to a makefile be removed. I object to this proposal, since it leaves debian/rules interface and behaviour unspecified in many instances. And there is already another proposal about this. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
On 20010301T172047+0100, Wichert Akkerman wrote: Previously Julian Gilbey wrote: debian/rules -q target exit status: 2 if target does not exist, !=2 otherwise This has *never* been required, was never documented anywhere, and is not needed at all. It is part of an accepted policy amendment. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
Bug#88111: policy should not dictate implementation details
Previously Antti-Juhani Kaijanaho wrote: That is false. Currently policy defines the interface of a debian/rules and even some of its behaviour by saying that it is a Makefile. Right, and my argument is that that is wrong. If debian/rules is a makefile or not is an implementation detail and should not be specified in policy. Policy should specify the interface to it. Please note we had this same discussion about a year ago and agreed that policy should indeed not sp cify that debian/rules is a makefile (which it did not back then). Feel free to browse through the mailinglist archives. If we decide to remove that requirement, we will need to specify its interface and behaviour another way. Indeed, see my patch in another mail. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
Previously Antti-Juhani Kaijanaho wrote: Also the debian/rules VAR=VALUE ... syntax is used by dpkg-buildpackage. Thanks for reminding me, I'll change that to use environment variables instead. Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Bug#88111: policy should not dictate implementation details
Previously Julian Gilbey wrote: Right. Give a policy diff which specifies *exactly* what interfaces are required of debian/rules. I'll make some other changes as well. I notice the current policy documented is poluted with things like scripting advise, which should be in a seperate document. Patch is attached. Wichert. -- _ / Nothing is fool-proof to a sufficiently talented fool \ | [EMAIL PROTECTED] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | --- policy.sgml.org Thu Mar 1 17:30:54 2001 +++ policy.sgml Thu Mar 1 17:43:03 2001 @@ -1230,50 +1230,6 @@ GNU GPL, just as the rest of prgndpkg/prgn is.)/p/sect1 - - sect1 - headingError trapping in makefiles/heading - - p - When prgnmake/prgn invokes a command in a makefile - (including your package's upstream makefiles and the - ttdebian/rules/tt) it does so using ttsh/tt. This - means that ttsh/tt's usual bad error handling - properties apply: if you include a miniature script as one - of the commands in your makefile you'll find that if you - don't do anything about it then errors are not detected - and prgnmake/prgn will blithely continue after - problems./p - - p - Every time you put more than one shell command (this - includes using a loop) in a makefile command you - must make sure that errors are trapped. For - simple compound commands, such as changing directory and - then running a program, using ttamp;amp;/tt rather - than semicolon as a command separator is sufficient. For - more complex commands including most loops and - conditionals you should include a separate ttset -e/tt - command at the start of every makefile command that's - actually one of these miniature shell scripts./p/sect1 - - - sect1 - headingObsolete constructs and libraries/heading - - p - The include file prgnlt;varargs.hgt;/prgn is - provided to support end-users compiling very old software; - the library ttlibtermcap/tt is provided to support the - execution of software which has been linked against it - (either old programs or those such as Netscape which are - only available in binary form)./p - - p - Debian packages should be ported to include - prgnlt;stdarg.hgt;/prgn and ttncurses/tt when - they are built./p - /sect1 /sect /chapt @@ -1734,15 +1690,16 @@ main building script/heading p - This file must be an executable makefile, and contains the + This file must be an executable, and contains the package-specific recipes for compiling the package and building binary package(s) out of the source. /p p - It must start with the line tt#!/usr/bin/make -f/tt, - so that it can be invoked by saying its name rather than - invoking prgnmake/prgn explicitly. + The ttdebian/rules/tt takes a single argument, which is + the target we want to build. Success should be indicated + using the exitcode: an exitcode of 0 indicates success, + any other code indicates a failure. /p p @@ -1773,39 +1730,10 @@ /p p - For some packages, notably ones where the same - source tree is compiled in different ways to produce - two binary packages, the prgnbuild/prgn target - does not make much sense. For these packages it is - good enough to provide two (or more) targets - (ttbuild-a/tt and ttbuild-b/tt or whatever) - for each of the ways of building the package, and a - prgnbuild/prgn target that does nothing. The - prgnbinary/prgn target will have to build the - package in each of the possible ways and make the - binary package out of each. - /p - - p The prgnbuild/prgn target must not do anything that might require root privilege. /p - p - The prgnbuild/prgn target may need to run - prgnclean/prgn first - see below. - /p - - p - When a package has a configuration routine that - takes a long time, or when the makefiles are poorly - designed, or when prgnbuild/prgn needs to run - prgnclean/prgn first, it is a good idea to - tttouch build/tt when the build process is - complete. This will ensure that if ttdebian/rules
Bug#88111: policy should not dictate implementation details
On 20010301T174940+0100, Wichert Akkerman wrote: Right, and my argument is that that is wrong. If debian/rules is a makefile or not is an implementation detail and should not be specified in policy. Policy should specify the interface to it. I have no problems with this, actually I agree. I just want to shoot down half-baked attempts to implement it :-) Indeed, see my patch in another mail. OK. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
