CINXE.COM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html><head> <link rel="icon" href="/favicon.png"> <title>#640874 - leave: debian/rules is not a Makefile - Debian Bug report logs</title> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <link rel="stylesheet" href="/css/bugs.css" type="text/css"> <link rel="canonical" href="<a href="bugreport.cgi?bug=640874">640874</a>"> <script type="text/javascript">  </script> </head> <body> <h1>Debian Bug report logs - <a href="mailto:640874@bugs.debian.org">#640874</a><br> leave: debian/rules is not a Makefile</h1> <div class="versiongraph"><a href="version.cgi?fixed=leave%2F1.12-2.1;absolute=0;package=leave;collapse=1;info=1"><img alt="version graph" src="version.cgi?width=2;package=leave;collapse=1;absolute=0;fixed=leave%2F1.12-2.1;height=2"></a></div> <div class="pkginfo"> <p>Package: <a class="submitter" href="pkgreport.cgi?package=leave">leave</a>; Maintainer for <a href="pkgreport.cgi?package=leave">leave</a> is <a href="pkgreport.cgi?maint=packages%40qa.debian.org">Debian QA Group <packages@qa.debian.org></a>; Source for <a href="pkgreport.cgi?package=leave">leave</a> is <a href="pkgreport.cgi?src=leave">src:leave</a> (<a href="https://tracker.debian.org/pkg/leave">PTS</a>, <a href="https://buildd.debian.org/leave">buildd</a>, <a href="https://qa.debian.org/popcon.php?package=leave">popcon</a>). </p> </div> <div class="buginfo"> <p>Reported by: <a href="pkgreport.cgi?submitter=niels%40thykier.net">Niels Thykier <niels@thykier.net></a></p> <p>Date: Thu, 8 Sep 2011 06:27:02 UTC</p> <p>Severity: <em class="severity">serious</em></p> <p>Tags: patch</p> <p>Fixed in version leave/1.12-2.1</p> <p><strong>Done:</strong> Sébastien Villemot <sebastien@debian.org></p> <p>Bug is archived. No further changes may be made.<p></div> <p><input id="uselessmesages" type="checkbox"><label for="uselessmessages">Display info messages</label></p><div class="msgreceived"><p>View this report as an <a href="bugreport.cgi?bug=640874;mbox=yes">mbox folder</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;mboxstatus=yes">status mbox</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;mboxmaint=yes">maintainer mbox</a></p></div> <div class="infmessage"><hr><p> <a name="1"></a>   <strong>Report forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Josip Rodin <joy-packages@debian.org></code>:<br> <code>Bug#640874</code>; Package <code>leave</code>. (Thu, 08 Sep 2011 06:27:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=2">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=2">mbox</a>, <a href="#1">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="3"></a>   <strong>Acknowledgement sent</strong> to <code>Niels Thykier <niels@thykier.net></code>:<br> New Bug report received and forwarded. Copy sent to <code>Josip Rodin <joy-packages@debian.org></code>. (Thu, 08 Sep 2011 06:27:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=4">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=4">mbox</a>, <a href="#3">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="5"></a><a name="msg5"></a><a href="#5">Message #5</a> received at submit@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=5">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=5">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E&In-Reply-To=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E&subject=Re%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Thu%2C%2008%20Sep%202011%2008%3A21%3A32%20%2B0200%20Niels%20Thykier%20%3Cniels%40thykier.net%3E%20wrote%3A%0A%3E%20Package%3A%20leave%0A%3E%20Severity%3A%20serious%0A%3E%20Justification%3A%20Policy%204.9%20-%20must%20directive%0A%3E%20User%3A%20lint-maint%40debian.org%0A%3E%20Usertags%3A%20debian-rules-not-a-makefile%20debian-rules-missing-required-target%20debian-rules-missing-recommended-target%0A%3E%20%0A%3E%20-----BEGIN%20PGP%20SIGNED%20MESSAGE-----%0A%3E%20Hash%3A%20SHA256%0A%3E%20%0A%3E%20Hi%0A%3E%20%0A%3E%20%22%22%22%0A%3E%204.9%20Main%20building%20script%3A%20debian%2Frules%0A%3E%20%0A%3E%20This%20file%20must%20be%20an%20executable%20makefile%2C%20and%20contains%20the%20package-specific%0A%3E%20recipes%20for%20compiling%20the%20package%20and%20building%20binary%20package%28s%29%20from%20the%0A%3E%20source.%0A%3E%20%0A%3E%20It%20must%20start%20with%20the%20line%20%23%21%2Fusr%2Fbin%2Fmake%20-f%2C%20so%20that%20it%20can%20be%20invoked%20by%0A%3E%20saying%20its%20name%20rather%20than%20invoking%20make%20explicitly.%20That%20is%2C%20invoking%0A%3E%20either%20of%20make%20-f%20debian%2Frules%20args...%20or%20.%2Fdebian%2Frules%20args...%20must%20result%0A%3E%20in%20identical%20behavior.%0A%3E%20%22%22%22%0A%3E%20%0A%3E%20~Niels%0A%3E%20%0A%3E%20-%20--%20System%20Information%3A%0A%3E%20Debian%20Release%3A%20wheezy%2Fsid%0A%3E%20%20%20APT%20prefers%20testing%0A%3E%20%20%20APT%20policy%3A%20%28990%2C%20%27testing%27%29%2C%20%28500%2C%20%27unstable%27%29%2C%20%281%2C%20%27experimental%27%29%0A%3E%20Architecture%3A%20i386%20%28i686%29%0A%3E%20%0A%3E%20Kernel%3A%20Linux%203.0.0-1-686-pae%20%28SMP%20w%2F2%20CPU%20cores%29%0A%3E%20Locale%3A%20LANG%3Den_DK.UTF-8%2C%20LC_CTYPE%3Den_DK.UTF-8%20%28charmap%3DUTF-8%29%0A%3E%20Shell%3A%20%2Fbin%2Fsh%20linked%20to%20%2Fbin%2Fdash%0A%3E%20%0A%3E%20-----BEGIN%20PGP%20SIGNATURE-----%0A%3E%20Version%3A%20GnuPG%20v1.4.11%20%28GNU%2FLinux%29%0A%3E%20%0A%3E%20iQIcBAEBCAAGBQJOaF7oAAoJEAVLu599gGRCTI4QAKUNmrvvysBkw2DcFvTnKdKY%0A%3E%20et%2Bme0LbciOResbRrtuNpOrx6mjfROijF34nozoCgarABLkV0eYKmyNY7W4D4xRl%0A%3E%207iEzMSJir5nfa55UL7XF%2Fn%2BkMZBoCb6S1oySi%2FtLdJwg5ffi776X6oWzmK2a%2FVZP%0A%3E%20yjjSA1WWn3ZUXyZKQEKHQ6dyIN6d%2B4N5bZjXcn4Pty8Kr684ZRSdAbo56Xs4A%2FJM%0A%3E%20booOhC%2BMJX8QIHY5p2YLc13lBc42IAv%2BBve61MIaq1Eh8UxTbPYALMyB38lGOxQE%0A%3E%20v%2BhrzNNdJxhvzBBgDM%2FTI72GRSCnTWMhNq%2BXbgsUwaRhtC%2FbL0kqTsemg4yyQ2IA%0A%3E%20UP8WLwSihjT%2Bv1%2Bh7wa2UxwHLHz2Xz4EmzyInjyImGbZkZ3FqR%2B%2BxjWLdqOPekkC%0A%3E%20d3p%2BtXaiTd7DzbMx57ySwGS1N82Puf4N%2BHsD6gqVrdEJ1ZDNa8zqQHjP09gKT%2FKd%0A%3E%20G%2Fy1XtVO8nwhShHCioDLD9ZUvCJNAnsir4vbOileEb9Evuc8odb%2BBnT4q4SrrPek%0A%3E%20rKxj%2F5emDKUcin30DVKqrdmSLNzDSuJmN5SwOWeXEo3DzOAfZI1fJoMurYR18fhG%0A%3E%203L5EC6MZFnd2uizYMtUwA5Eg8gPGJrjVEw7Ly9D28Vixq5k4vb8AlaPqNCR8wgkn%0A%3E%20ezdzcapjp2lWO5umJ01q%0A%3E%20%3D684B%0A%3E%20-----END%20PGP%20SIGNATURE-----%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=niels%40thykier.net" alt=""> <div class="header"><span class="headerfield">From:</span> Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">To:</span> Debian Bug Tracking System <submit@bugs.debian.org></div> <div class="header"><span class="headerfield">Subject:</span> leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 08 Sep 2011 08:21:32 +0200</div> </div> <pre class="message">Package: leave Severity: serious Justification: Policy 4.9 - must directive User: lint-maint@debian.org Usertags: debian-rules-not-a-makefile debian-rules-missing-required-target debian-rules-missing-recommended-target -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi """ 4.9 Main building script: debian/rules 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. 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 is, invoking either of make -f debian/rules args... or ./debian/rules args... must result in identical behavior. """ ~Niels - -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.0.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJOaF7oAAoJEAVLu599gGRCTI4QAKUNmrvvysBkw2DcFvTnKdKY et+me0LbciOResbRrtuNpOrx6mjfROijF34nozoCgarABLkV0eYKmyNY7W4D4xRl 7iEzMSJir5nfa55UL7XF/n+kMZBoCb6S1oySi/tLdJwg5ffi776X6oWzmK2a/VZP yjjSA1WWn3ZUXyZKQEKHQ6dyIN6d+4N5bZjXcn4Pty8Kr684ZRSdAbo56Xs4A/JM booOhC+MJX8QIHY5p2YLc13lBc42IAv+Bve61MIaq1Eh8UxTbPYALMyB38lGOxQE v+hrzNNdJxhvzBBgDM/TI72GRSCnTWMhNq+XbgsUwaRhtC/bL0kqTsemg4yyQ2IA UP8WLwSihjT+v1+h7wa2UxwHLHz2Xz4EmzyInjyImGbZkZ3FqR++xjWLdqOPekkC d3p+tXaiTd7DzbMx57ySwGS1N82Puf4N+HsD6gqVrdEJ1ZDNa8zqQHjP09gKT/Kd G/y1XtVO8nwhShHCioDLD9ZUvCJNAnsir4vbOileEb9Evuc8odb+BnT4q4SrrPek rKxj/5emDKUcin30DVKqrdmSLNzDSuJmN5SwOWeXEo3DzOAfZI1fJoMurYR18fhG 3L5EC6MZFnd2uizYMtUwA5Eg8gPGJrjVEw7Ly9D28Vixq5k4vb8AlaPqNCR8wgkn ezdzcapjp2lWO5umJ01q =684B -----END PGP SIGNATURE----- </pre> <div class="infmessage"><hr><p> <a name="6"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Josip Rodin <joy-packages@debian.org></code>:<br> <code>Bug#640874</code>; Package <code>leave</code>. (Thu, 08 Sep 2011 08:03:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=7">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=7">mbox</a>, <a href="#6">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="8"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Josip Rodin <joy-packages@debian.org></code>. (Thu, 08 Sep 2011 08:03:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=9">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=9">mbox</a>, <a href="#8">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="10"></a><a name="msg10"></a><a href="#10">Message #10</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=10">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=10">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%208%20Sep%202011%2009%3A59%3A40%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20reassign%20640874%20tech-ctte%0A%3E%20thanks%0A%3E%20%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2008%3A21%3A32AM%20%2B0200%2C%20Niels%20Thykier%20wrote%3A%0A%3E%20%3E%20Package%3A%20leave%0A%3E%20%3E%20Severity%3A%20serious%0A%3E%20%3E%20Justification%3A%20Policy%204.9%20-%20must%20directive%0A%3E%20%3E%20User%3A%20lint-maint%40debian.org%0A%3E%20%3E%20Usertags%3A%20debian-rules-not-a-makefile%20debian-rules-missing-required-target%20debian-rules-missing-recommended-target%0A%3E%20%0A%3E%20The%20policy%20wording%20was%20hardcoded%20like%20that%20basically%20because%20Manoj%20is%20overly%0A%3E%20attached%20to%20make%2C%20we%20had%20long%20and%20unfruitful%20discussions%20about%20it%20%28I%20forget%0A%3E%20the%20bug%20number%2C%20search%20the%20archives%29%2C%20and%20no%20actual%20practical%20reason%20to%0A%3E%20change%20this%20has%20ever%20been%20demonstrated.%0A%3E%20%0A%3E%20Well%2C%20there%27s%20one%20-%20I%20can%27t%20upload%20a%20new%20version%20because%20Joerg%20decided%20some%0A%3E%20time%20ago%20to%20be%20similarly%20anal%2C%20too.%0A%3E%20%0A%3E%20It%27s%20all%20a%20big%2C%20silly%20exercise%20in%20stubbornness.%20It%20must%20be%20a%20makefile%21%0A%3E%20It%20doesn%27t%20matter%20if%20there%27s%20no%20practical%20purpose%20to%20it%2C%20it%20still%20must%20be%21%0A%3E%20It%20%2Amust%2A%21%0A%3E%20%0A%3E%20It%27s%20the%20kind%20of%20stuff%20that%20makes%20me%20quite%20disillusioned%20with%20Debian...%0A%3E%20Yes%2C%20you%20can%20say%20that%20silliness%20has%20infected%20me%2C%20too.%0A%3E%20%0A%3E%20But%20if%20I%27ve%20maintained%20this%20precedent%20this%20long%2C%20there%27s%20no%20point%20in%20giving%0A%3E%20it%20up%20now%20%3A%29%20I%27m%20referring%20this%20to%20the%20technical%20committee%2C%20hopefully%20they%0A%3E%20haven%27t%20turned%20into%20robots%20and%20have%20some%20good%20sense%20to%20leave%20leave%20be.%20%28heh%29%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E&In-Reply-To=%3C20110908075940.GA2168%40entuzijast.net%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Niels Thykier <niels@thykier.net>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> control@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 09:59:40 +0200</div> </div> <pre class="message">reassign 640874 tech-ctte thanks On Thu, Sep 08, 2011 at 08:21:32AM +0200, Niels Thykier wrote: > Package: leave > Severity: serious > Justification: Policy 4.9 - must directive > User: lint-maint@debian.org > Usertags: debian-rules-not-a-makefile debian-rules-missing-required-target debian-rules-missing-recommended-target The policy wording was hardcoded like that basically because Manoj is overly attached to make, we had long and unfruitful discussions about it (I forget the bug number, search the archives), and no actual practical reason to change this has ever been demonstrated. Well, there's one - I can't upload a new version because Joerg decided some time ago to be similarly anal, too. It's all a big, silly exercise in stubbornness. It must be a makefile! It doesn't matter if there's no practical purpose to it, it still must be! It *must*! It's the kind of stuff that makes me quite disillusioned with Debian... Yes, you can say that silliness has infected me, too. But if I've maintained this precedent this long, there's no point in giving it up now :) I'm referring this to the technical committee, hopefully they haven't turned into robots and have some good sense to leave leave be. (heh) -- 2. That which causes joy or happiness. </pre> <div class="msgreceived"><hr><p> <a name="11"></a>       <strong>Bug reassigned from package '<a href="pkgreport.cgi?package=leave">leave</a>' to '<a href="pkgreport.cgi?package=tech-ctte">tech-ctte</a>'.</strong> Request was from <code>Josip Rodin <joy@debbugs.entuzijast.net></code> to <code>control@bugs.debian.org</code>. (Thu, 08 Sep 2011 08:03:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=12">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=12">mbox</a>, <a href="#11">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="13"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 09:48:20 GMT) (<a href="bugreport.cgi?bug=640874;msg=14">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=14">mbox</a>, <a href="#13">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="15"></a>   <strong>Acknowledgement sent</strong> to <code>Colin Watson <cjwatson@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 09:48:44 GMT) (<a href="bugreport.cgi?bug=640874;msg=16">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=16">mbox</a>, <a href="#15">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="17"></a><a name="msg17"></a><a href="#17">Message #17</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=17">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=17">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E&In-Reply-To=%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E&body=On%20Thu%2C%208%20Sep%202011%2010%3A43%3A44%20%2B0100%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2009%3A59%3A40AM%20%2B0200%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20The%20policy%20wording%20was%20hardcoded%20like%20that%20basically%20because%20Manoj%20is%20overly%0A%3E%20%3E%20attached%20to%20make%2C%20we%20had%20long%20and%20unfruitful%20discussions%20about%20it%20%28I%20forget%0A%3E%20%3E%20the%20bug%20number%2C%20search%20the%20archives%29%2C%20and%20no%20actual%20practical%20reason%20to%0A%3E%20%3E%20change%20this%20has%20ever%20been%20demonstrated.%0A%3E%20%3E%20%0A%3E%20%3E%20Well%2C%20there%27s%20one%20-%20I%20can%27t%20upload%20a%20new%20version%20because%20Joerg%20decided%20some%0A%3E%20%3E%20time%20ago%20to%20be%20similarly%20anal%2C%20too.%0A%3E%20%3E%20%0A%3E%20%3E%20It%27s%20all%20a%20big%2C%20silly%20exercise%20in%20stubbornness.%20It%20must%20be%20a%20makefile%21%0A%3E%20%3E%20It%20doesn%27t%20matter%20if%20there%27s%20no%20practical%20purpose%20to%20it%2C%20it%20still%20must%20be%21%0A%3E%20%3E%20It%20%2Amust%2A%21%0A%3E%20%0A%3E%20I%20understand%20the%20inertial%20argument%20here%3B%20it%20feels%20bad%20to%20have%20to%20change%0A%3E%20without%20a%20clear%20reason%20being%20given%20to%20you.%0A%3E%20%0A%3E%20On%20the%20other%20hand%2C%20at%20this%20point%20there%20is%20also%20inertia%20attached%20to%20the%0A%3E%20fact%20that%20every%20single%20other%20package%20in%20Debian%20%28according%20to%0A%3E%20http%3A%2F%2Flintian.debian.org%2Ftags%2Fdebian-rules-not-a-makefile.html%29%20has%0A%3E%20debian%2Frules%20as%20a%20Makefile.%20%20Would%20you%20mind%20explaining%20here%20why%20you%20feel%0A%3E%20it%20is%20important%20to%20retain%20the%20flexibility%20of%20multiple%20implementation%0A%3E%20languages%20for%20debian%2Frules%3F%0A%3E%20%0A%3E%20I%20can%20provide%20a%20concrete%20practical%20reason%20for%20requiring%20make%20as%20the%0A%3E%20implementation%20language%3A%20at%20least%20one%2C%20probably%20two%2C%20of%20the%20options%20for%0A%3E%20build-arch%20handling%0A%3E%20%28http%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D629385%2393%29%20require%0A%3E%20debian%2Frules%20to%20be%20a%20Makefile.%20%20The%20leave%20package%20might%20be%20able%20to%20get%0A%3E%20away%20with%20a%20little%20bit%20more%20if%20its%20exit%20code%20matched%20that%20of%20make%20for%0A%3E%20nonexisting%20targets%2C%20mentioned%20in%20policy%204.9%3B%20however%2C%20it%20exits%201%20rather%0A%3E%20than%202%20in%20this%20case.%20%20I%20realise%20that%20this%20may%20be%20because%20you%20are%20unable%0A%3E%20to%20upload%20new%20versions%20with%20the%20shell%20implementation.%0A%3E%20%0A%3E%20Even%20if%20we%20end%20up%20not%20doing%20target%20autodetection%20for%20build-arch%2C%20it%0A%3E%20seems%20clear%20that%20having%20the%20option%20of%20doing%20so%20is%20useful%2C%20and%20that%20there%0A%3E%20is%20a%20cost%20to%20the%20project%20associated%20with%20every%20discussion%20on%20the%20subject%0A%3E%20having%20to%20consider%20the%20single%20exception%20where%20tools%20like%20%27make%20-qn%27%0A%3E%20won%27t%20work.%20%20I%20think%20we%20should%20only%20allow%20that%20exception%20if%20there%20is%20a%0A%3E%20corresponding%20benefit%20to%20doing%20so%2C%20beyond%20inertia.%0A%3E%20%0A%3E%20Regards%2C%0A%3E%20%0A%3E%20--%20%0A%3E%20Colin%20Watson%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%5Bcjwatson%40debian.org%5D%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=cjwatson%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 10:43:44 +0100</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 09:59:40AM +0200, Josip Rodin wrote: > The policy wording was hardcoded like that basically because Manoj is overly > attached to make, we had long and unfruitful discussions about it (I forget > the bug number, search the archives), and no actual practical reason to > change this has ever been demonstrated. > > Well, there's one - I can't upload a new version because Joerg decided some > time ago to be similarly anal, too. > > It's all a big, silly exercise in stubbornness. It must be a makefile! > It doesn't matter if there's no practical purpose to it, it still must be! > It *must*! I understand the inertial argument here; it feels bad to have to change without a clear reason being given to you. On the other hand, at this point there is also inertia attached to the fact that every single other package in Debian (according to <a href="http://lintian.debian.org/tags/debian-rules-not-a-makefile.html">http://lintian.debian.org/tags/debian-rules-not-a-makefile.html</a>) has debian/rules as a Makefile. Would you mind explaining here why you feel it is important to retain the flexibility of multiple implementation languages for debian/rules? I can provide a concrete practical reason for requiring make as the implementation language: at least one, probably two, of the options for build-arch handling (<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93</a>) require debian/rules to be a Makefile. The leave package might be able to get away with a little bit more if its exit code matched that of make for nonexisting targets, mentioned in policy 4.9; however, it exits 1 rather than 2 in this case. I realise that this may be because you are unable to upload new versions with the shell implementation. Even if we end up not doing target autodetection for build-arch, it seems clear that having the option of doing so is useful, and that there is a cost to the project associated with every discussion on the subject having to consider the single exception where tools like 'make -qn' won't work. I think we should only allow that exception if there is a corresponding benefit to doing so, beyond inertia. Regards, -- Colin Watson [cjwatson@debian.org] </pre> <div class="infmessage"><hr><p> <a name="18"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 09:54:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=19">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=19">mbox</a>, <a href="#18">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="20"></a>   <strong>Acknowledgement sent</strong> to <code>Colin Watson <cjwatson@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 09:54:23 GMT) (<a href="bugreport.cgi?bug=640874;msg=21">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=21">mbox</a>, <a href="#20">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="22"></a><a name="msg22"></a><a href="#22">Message #22</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=22">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=22">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%208%20Sep%202011%2010%3A50%3A33%20%2B0100%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2010%3A43%3A44AM%20%2B0100%2C%20Colin%20Watson%20wrote%3A%0A%3E%20%3E%20I%20can%20provide%20a%20concrete%20practical%20reason%20for%20requiring%20make%20as%20the%0A%3E%20%3E%20implementation%20language%3A%20at%20least%20one%2C%20probably%20two%2C%20of%20the%20options%20for%0A%3E%20%3E%20build-arch%20handling%0A%3E%20%3E%20%28http%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D629385%2393%29%20require%0A%3E%20%3E%20debian%2Frules%20to%20be%20a%20Makefile.%20%20The%20leave%20package%20might%20be%20able%20to%20get%0A%3E%20%3E%20away%20with%20a%20little%20bit%20more%20if%20its%20exit%20code%20matched%20that%20of%20make%20for%0A%3E%20%3E%20nonexisting%20targets%2C%20mentioned%20in%20policy%204.9%3B%20however%2C%20it%20exits%201%20rather%0A%3E%20%3E%20than%202%20in%20this%20case.%20%20I%20realise%20that%20this%20may%20be%20because%20you%20are%20unable%0A%3E%20%3E%20to%20upload%20new%20versions%20with%20the%20shell%20implementation.%0A%3E%20%0A%3E%20Although%20actually%2C%20Steve%20pointed%20out%20in%20message%20%23119%20that%20make%20will%20exit%0A%3E%202%20when%20presented%20with%20a%20shell%20script%2C%20so%20option%201%20would%20work%20for%20the%0A%3E%20leave%20package.%20%20Nevertheless%2C%20merely%20having%20that%20doubt%20in%20developers%27%0A%3E%20minds%20is%20a%20cost%3B%2017058%20packages%20can%20definitely%20use%20this%20technique%2C%20while%0A%3E%20for%201%20package%20we%20have%20to%20think%20about%20it%20...%20so%20I%20would%20still%20want%20to%0A%3E%20hear%20of%20a%20clear%20benefit%20to%20allowing%20this%20flexibility.%0A%3E%20%0A%3E%20Regards%2C%0A%3E%20%0A%3E%20--%20%0A%3E%20Colin%20Watson%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%5Bcjwatson%40debian.org%5D%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&In-Reply-To=%3C20110908095033.GA491%40riva.dynamic.greenend.org.uk%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908095033.GA491%40riva.dynamic.greenend.org.uk%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=cjwatson%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 10:50:33 +0100</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 10:43:44AM +0100, Colin Watson wrote: > I can provide a concrete practical reason for requiring make as the > implementation language: at least one, probably two, of the options for > build-arch handling > (<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93</a>) require > debian/rules to be a Makefile. The leave package might be able to get > away with a little bit more if its exit code matched that of make for > nonexisting targets, mentioned in policy 4.9; however, it exits 1 rather > than 2 in this case. I realise that this may be because you are unable > to upload new versions with the shell implementation. Although actually, Steve pointed out in message #119 that make will exit 2 when presented with a shell script, so option 1 would work for the leave package. Nevertheless, merely having that doubt in developers' minds is a cost; 17058 packages can definitely use this technique, while for 1 package we have to think about it ... so I would still want to hear of a clear benefit to allowing this flexibility. Regards, -- Colin Watson [cjwatson@debian.org] </pre> <div class="infmessage"><hr><p> <a name="23"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 12:42:51 GMT) (<a href="bugreport.cgi?bug=640874;msg=24">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=24">mbox</a>, <a href="#23">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="25"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 12:42:55 GMT) (<a href="bugreport.cgi?bug=640874;msg=26">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=26">mbox</a>, <a href="#25">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="27"></a><a name="msg27"></a><a href="#27">Message #27</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=27">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=27">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E&In-Reply-To=%3C20110908123815.GA13055%40entuzijast.net%3E&body=On%20Thu%2C%208%20Sep%202011%2014%3A38%3A15%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2010%3A43%3A44AM%20%2B0100%2C%20Colin%20Watson%20wrote%3A%0A%3E%20%3E%20Would%20you%20mind%20explaining%20here%20why%20you%20feel%20it%20is%20important%20to%20retain%20the%0A%3E%20%3E%20flexibility%20of%20multiple%20implementation%20languages%20for%20debian%2Frules%3F%0A%3E%20%0A%3E%20Now%2C%20I%20wouldn%27t%20actually%20put%20it%20that%20way%20-%20because%20that%20would%20imply%20that%20we%0A%3E%20could%20suddenly%20have%20a%20plethora%20of%20implementation%20languages%20for%20debian%2Frules%2C%0A%3E%20which%20might%20actually%20become%20detrimental%20and%20that%20as%20such%20cannot%20and%0A%3E%20shouldn%27t%20be%20an%20important%20goal.%0A%3E%20%0A%3E%20Instead%2C%20it%20is%20important%20to%20retain%20the%20age-old%20idea%20that%20the%20rules%20file%20has%0A%3E%20its%20own%20calling%20convention%20%28an%20API%29%20that%20isn%27t%20linked%20to%20one%20specific%0A%3E%20implementation%20and%20is%20instead%20properly%20specified%20in%20Debian%20policy%2C%20allowing%0A%3E%20developers%20some%20common-sense%20leeway%20and%20the%20ability%20to%20adjust%20the%20API%20if%20and%0A%3E%20when%20necessary.%0A%3E%20%0A%3E%20But%2C%20to%20return%20to%20the%20former%20idea%20of%20arguing%20for%20flexibility%20for%20just%20one%0A%3E%20moment%20-%20that%27s%20moot%20because%20of%20another%20reason%20-%20we%20%2Aalready%2A%20allow%20a%0A%3E%20near-infinite%20amount%20of%20abuse%20through%20flexibility%2C%20because%20you%20can%20make%20a%0A%3E%20makefile%20fork%20another%20program%20and%20do%20whatever%20afterwards.%20It%20would%20abide%20by%0A%3E%20the%20letter%20of%20the%20rules%2C%20and%20people%20have%20suggested%20to%20me%20that%20I%20do%20that%2C%20but%0A%3E%20I%20don%27t%20think%20that%20would%20be%20in%20line%20with%20the%20spirit%20of%20the%20rules%2C%20which%0A%3E%20provide%20a%20nice%2C%20clean%20description%20of%20what%20gets%20done%20for%20which%20specified%0A%3E%20action%20or%20variable%2C%20so%20the%20code%20should%20roughly%20match%20such%20a%20description%0A%3E%20without%20a%20lot%20of%20necessary%20overhead.%0A%3E%20%0A%3E%20Heck%2C%20even%20the%20typical%20dh%281%29%20debian%2Frules%20file%20%28so%20typical%20I%20pasted%20it%0A%3E%20straight%20from%20its%20manual%20page%29%3A%0A%3E%20%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20dh%20%24%40%0A%3E%20%0A%3E%20does%20not%20strike%20me%20as%20better%20than%20a%20shell%20script%20such%20as%20the%20one%20used%20by%0A%3E%20leave%27s%20debian%2Frules%20file%20-%20in%20fact%20it%27s%20seems%20more%20opaque%20and%20needs%20more%0A%3E%20documentation%2Fknowledge%20to%20figure%20out%20in%20what%20way%20does%20this%20follow%0A%3E%20the%20rules%20set%20out%20in%20the%20policy.%0A%3E%20%0A%3E%20%3E%20I%20can%20provide%20a%20concrete%20practical%20reason%20for%20requiring%20make%20as%20the%0A%3E%20%3E%20implementation%20language%3A%20at%20least%20one%2C%20probably%20two%2C%20of%20the%20options%20for%0A%3E%20%3E%20build-arch%20handling%0A%3E%20%3E%20%28http%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D629385%2393%29%20require%0A%3E%20%3E%20debian%2Frules%20to%20be%20a%20Makefile.%20%20The%20leave%20package%20might%20be%20able%20to%20get%0A%3E%20%3E%20away%20with%20a%20little%20bit%20more%20if%20its%20exit%20code%20matched%20that%20of%20make%20for%0A%3E%20%3E%20nonexisting%20targets%2C%20mentioned%20in%20policy%204.9%3B%20however%2C%20it%20exits%201%20rather%0A%3E%20%3E%20than%202%20in%20this%20case.%20%20I%20realise%20that%20this%20may%20be%20because%20you%20are%20unable%0A%3E%20%3E%20to%20upload%20new%20versions%20with%20the%20shell%20implementation.%0A%3E%20%0A%3E%20Implementing%20a%20return%20code%20handler%20seems%20perfectly%20sensible.%20The%20idea%20that%0A%3E%20programs%20can%20return%20a%20variety%20of%20codes%20to%20indicate%20a%20variety%20of%20conditions%0A%3E%20is%20both%20ancient%20and%20pervasive.%20Even%20testing%20the%20result%20of%20make%20-qn%20is%0A%3E%20basically%20repeating%20the%20same%20thing%2C%20so%20why%20add%20an%20additional%20dependency%3F%0A%3E%20%0A%3E%20The%20whole%20idea%20that%20we%27re%20changing%20something%20in%20the%20build-arch%20handling%20is%20a%0A%3E%20nice%20supporting%20argument%20for%20my%20idea%20that%20we%20don%27t%20have%20a%20reason%20to%20hardcode%0A%3E%20make%20-%20the%20fact%20that%20we%20control%20the%20API%20means%20that%20we%20are%20able%20to%20make%20this%0A%3E%20decision%2C%20rather%20than%20having%20to%20adjust%20to%20whatever%20some%20semi-random%20program%0A%3E%20does.%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org, Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 14:38:15 +0200</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 10:43:44AM +0100, Colin Watson wrote: > Would you mind explaining here why you feel it is important to retain the > flexibility of multiple implementation languages for debian/rules? Now, I wouldn't actually put it that way - because that would imply that we could suddenly have a plethora of implementation languages for debian/rules, which might actually become detrimental and that as such cannot and shouldn't be an important goal. Instead, it is important to retain the age-old idea that the rules file has its own calling convention (an API) that isn't linked to one specific implementation and is instead properly specified in Debian policy, allowing developers some common-sense leeway and the ability to adjust the API if and when necessary. But, to return to the former idea of arguing for flexibility for just one moment - that's moot because of another reason - we *already* allow a near-infinite amount of abuse through flexibility, because you can make a makefile fork another program and do whatever afterwards. It would abide by the letter of the rules, and people have suggested to me that I do that, but I don't think that would be in line with the spirit of the rules, which provide a nice, clean description of what gets done for which specified action or variable, so the code should roughly match such a description without a lot of necessary overhead. Heck, even the typical dh(1) debian/rules file (so typical I pasted it straight from its manual page): #!/usr/bin/make -f %: dh $@ does not strike me as better than a shell script such as the one used by leave's debian/rules file - in fact it's seems more opaque and needs more documentation/knowledge to figure out in what way does this follow the rules set out in the policy. > I can provide a concrete practical reason for requiring make as the > implementation language: at least one, probably two, of the options for > build-arch handling > (<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93</a>) require > debian/rules to be a Makefile. The leave package might be able to get > away with a little bit more if its exit code matched that of make for > nonexisting targets, mentioned in policy 4.9; however, it exits 1 rather > than 2 in this case. I realise that this may be because you are unable > to upload new versions with the shell implementation. Implementing a return code handler seems perfectly sensible. The idea that programs can return a variety of codes to indicate a variety of conditions is both ancient and pervasive. Even testing the result of make -qn is basically repeating the same thing, so why add an additional dependency? The whole idea that we're changing something in the build-arch handling is a nice supporting argument for my idea that we don't have a reason to hardcode make - the fact that we control the API means that we are able to make this decision, rather than having to adjust to whatever some semi-random program does. -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="28"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 12:57:30 GMT) (<a href="bugreport.cgi?bug=640874;msg=29">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=29">mbox</a>, <a href="#28">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="30"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 12:57:42 GMT) (<a href="bugreport.cgi?bug=640874;msg=31">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=31">mbox</a>, <a href="#30">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="32"></a><a name="msg32"></a><a href="#32">Message #32</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=32">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=32">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Thu%2C%208%20Sep%202011%2014%3A55%3A00%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2010%3A50%3A33AM%20%2B0100%2C%20Colin%20Watson%20wrote%3A%0A%3E%20%3E%20Nevertheless%2C%20merely%20having%20that%20doubt%20in%20developers%27%20minds%20is%20a%20cost%3B%0A%3E%20%3E%2017058%20packages%20can%20definitely%20use%20this%20technique%2C%20while%20for%201%20package%20we%0A%3E%20%3E%20have%20to%20think%20about%20it%20...%20so%20I%20would%20still%20want%20to%20hear%20of%20a%20clear%0A%3E%20%3E%20benefit%20to%20allowing%20this%20flexibility.%0A%3E%20%0A%3E%20Every%20debian%2Frules%20file%20is%20a%20source%20of%20doubt%20-%20you%20can%27t%20rely%20on%20them%20doing%0A%3E%20anything%20other%20than%20what%20is%20specified%20in%20the%20true%20elements%20of%20the%20API%0A%3E%20-%20program%20arguments%2C%20environment%20variables%2C%20return%20codes...%0A%3E%20%0A%3E%20The%20requirement%20that%20the%20internal%20structure%20of%20the%20program%20matches%20something%0A%3E%20make%281%29%20can%20parse%20did%20not%20really%20create%20a%20new%20API%2C%20nor%20did%20it%20do%20much%20to%0A%3E%20remove%20doubt%20on%20what%20the%20developers%20can%20find%20when%20examining%20debian%2Frules%0A%3E%20files.%0A%3E%20%0A%3E%20It%20was%20just%20an%20arbitrary%20conversion%20of%20a%20single%20%22is%22%20to%20%22must%20be%22%20%28in%20an%0A%3E%20unrelated%20let%27s-use-consistent-RFC-like-wording%20drive%29%20that%20went%20unchecked.%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A%3E%20%0A%3E%20%0A%3E%20%0A&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908095033.GA491%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908125500.GA17694%40entuzijast.net%3E&In-Reply-To=%3C20110908125500.GA17694%40entuzijast.net%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org, Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 14:55:00 +0200</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 10:50:33AM +0100, Colin Watson wrote: > Nevertheless, merely having that doubt in developers' minds is a cost; > 17058 packages can definitely use this technique, while for 1 package we > have to think about it ... so I would still want to hear of a clear > benefit to allowing this flexibility. Every debian/rules file is a source of doubt - you can't rely on them doing anything other than what is specified in the true elements of the API - program arguments, environment variables, return codes... The requirement that the internal structure of the program matches something make(1) can parse did not really create a new API, nor did it do much to remove doubt on what the developers can find when examining debian/rules files. It was just an arbitrary conversion of a single "is" to "must be" (in an unrelated let's-use-consistent-RFC-like-wording drive) that went unchecked. -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="33"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 13:42:12 GMT) (<a href="bugreport.cgi?bug=640874;msg=34">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=34">mbox</a>, <a href="#33">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="35"></a>   <strong>Acknowledgement sent</strong> to <code>Raphael Hertzog <hertzog@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 13:42:12 GMT) (<a href="bugreport.cgi?bug=640874;msg=36">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=36">mbox</a>, <a href="#35">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="37"></a><a name="msg37"></a><a href="#37">Message #37</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=37">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=37">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%208%20Sep%202011%2015%3A38%3A39%20%2B0200%20Raphael%20Hertzog%20%3Chertzog%40debian.org%3E%20wrote%3A%0A%3E%20Hi%20Josip%2C%0A%3E%20%0A%3E%20On%20Thu%2C%2008%20Sep%202011%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20Instead%2C%20it%20is%20important%20to%20retain%20the%20age-old%20idea%20that%20the%20rules%20file%20has%0A%3E%20%3E%20its%20own%20calling%20convention%20%28an%20API%29%20that%20isn%27t%20linked%20to%20one%20specific%0A%3E%20%3E%20implementation%20and%20is%20instead%20properly%20specified%20in%20Debian%20policy%2C%20allowing%0A%3E%20%3E%20developers%20some%20common-sense%20leeway%20and%20the%20ability%20to%20adjust%20the%20API%20if%20and%0A%3E%20%3E%20when%20necessary.%0A%3E%20%0A%3E%20The%20API%20is%20not%20the%20only%20thing%20to%20take%20into%20account.%20Using%20anything%20else%0A%3E%20than%20make%20is%20unexpected%20for%20most%20other%20developers%20%28some%20of%20them%20who%20might%0A%3E%20have%20to%20NMU%20your%20package%20at%20some%20point%29.%0A%3E%20%0A%3E%20%3E%20Heck%2C%20even%20the%20typical%20dh%281%29%20debian%2Frules%20file%20%28so%20typical%20I%20pasted%20it%0A%3E%20%3E%20straight%20from%20its%20manual%20page%29%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20dh%20%24%40%0A%3E%20%3E%20%0A%3E%20%3E%20does%20not%20strike%20me%20as%20better%20than%20a%20shell%20script%20such%20as%20the%20one%20used%20by%0A%3E%20%3E%20leave%27s%20debian%2Frules%20file%20-%20in%20fact%20it%27s%20seems%20more%20opaque%20and%20needs%20more%0A%3E%20%3E%20documentation%2Fknowledge%20to%20figure%20out%20in%20what%20way%20does%20this%20follow%0A%3E%20%3E%20the%20rules%20set%20out%20in%20the%20policy.%0A%3E%20%0A%3E%20Yes%2C%20but%20it%27s%20also%20not%20worse%20than%20having%20to%20read%20the%20sources%20of%20a%20shell%0A%3E%20script.%0A%3E%20%0A%3E%20And%20still%2C%20this%20is%20a%20Makefile%20so%20you%20can%20quickly%20reuse%20Makefile%20snippets%0A%3E%20that%20others%20have%20been%20writing%20to%20add%20support%20for%20supplementary%20targets%0A%3E%20%28like%20get-orig-source%29%20or%20even%20to%20influence%20the%20environment%20%28like%20the%0A%3E%20Makefile%20snippets%20that%20dpkg%201.16.1%20is%20going%20to%20provide%29.%0A%3E%20%0A%3E%20%0A%3E%20So%20I%20really%20don%27t%20understand%20why%20you%20insist%20on%20keeping%20debian%2Frules%0A%3E%20as%20a%20shell%20script.%20Moving%20it%20one%20level%20deeper%20in%20the%20process%20tree%0A%3E%20does%20not%20strike%20me%20as%20a%20big%20performance%2Freadability%20loss%2C%20certainly%20not%0A%3E%20one%20worth%20spending%20the%20time%20of%20tech-ctte%20members%20on%20such%20a%20case.%0A%3E%20%0A%3E%20%3E%20The%20whole%20idea%20that%20we%27re%20changing%20something%20in%20the%20build-arch%20handling%20is%20a%0A%3E%20%3E%20nice%20supporting%20argument%20for%20my%20idea%20that%20we%20don%27t%20have%20a%20reason%20to%20hardcode%0A%3E%20%3E%20make%20-%20the%20fact%20that%20we%20control%20the%20API%20means%20that%20we%20are%20able%20to%20make%20this%0A%3E%20%3E%20decision%2C%20rather%20than%20having%20to%20adjust%20to%20whatever%20some%20semi-random%20program%0A%3E%20%3E%20does.%0A%3E%20%0A%3E%20If%20you%20ignore%20all%20transitions%20constraints%2C%20sure.%20At%20the%20same%20time%2C%20Debian%0A%3E%20decided%20debian%2Frules%20must%20be%20a%20Makefile%20and%20you%27re%20not%20adjusting%20to%20cope.%0A%3E%20%0A%3E%20Why%20should%20you%20better%20accept%20another%20API%20design%20compared%20to%20an%20already%0A%3E%20existing%20policy%20requirement%3F%0A%3E%20%0A%3E%20Cheers%2C%0A%3E%20--%20%0A%3E%20Rapha%C3%ABl%20Hertzog%20%E2%97%88%20Debian%20Developer%0A%3E%20%0A%3E%20Follow%20my%20Debian%20News%20%E2%96%B6%20http%3A%2F%2FRaphaelHertzog.com%20%28English%29%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%E2%96%B6%20http%3A%2F%2FRaphaelHertzog.fr%20%28Fran%C3%A7ais%29%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E&In-Reply-To=%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=hertzog%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 15:38:39 +0200</div> </div> <pre class="message">Hi Josip, On Thu, 08 Sep 2011, Josip Rodin wrote: > Instead, it is important to retain the age-old idea that the rules file has > its own calling convention (an API) that isn't linked to one specific > implementation and is instead properly specified in Debian policy, allowing > developers some common-sense leeway and the ability to adjust the API if and > when necessary. The API is not the only thing to take into account. Using anything else than make is unexpected for most other developers (some of them who might have to NMU your package at some point). > Heck, even the typical dh(1) debian/rules file (so typical I pasted it > straight from its manual page): > > #!/usr/bin/make -f > %: > dh $@ > > does not strike me as better than a shell script such as the one used by > leave's debian/rules file - in fact it's seems more opaque and needs more > documentation/knowledge to figure out in what way does this follow > the rules set out in the policy. Yes, but it's also not worse than having to read the sources of a shell script. And still, this is a Makefile so you can quickly reuse Makefile snippets that others have been writing to add support for supplementary targets (like get-orig-source) or even to influence the environment (like the Makefile snippets that dpkg 1.16.1 is going to provide). So I really don't understand why you insist on keeping debian/rules as a shell script. Moving it one level deeper in the process tree does not strike me as a big performance/readability loss, certainly not one worth spending the time of tech-ctte members on such a case. > The whole idea that we're changing something in the build-arch handling is a > nice supporting argument for my idea that we don't have a reason to hardcode > make - the fact that we control the API means that we are able to make this > decision, rather than having to adjust to whatever some semi-random program > does. If you ignore all transitions constraints, sure. At the same time, Debian decided debian/rules must be a Makefile and you're not adjusting to cope. Why should you better accept another API design compared to an already existing policy requirement? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ <a href="http://RaphaelHertzog.com">http://RaphaelHertzog.com</a> (English) ▶ <a href="http://RaphaelHertzog.fr">http://RaphaelHertzog.fr</a> (Français) </pre> <div class="infmessage"><hr><p> <a name="38"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 14:21:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=39">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=39">mbox</a>, <a href="#38">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="40"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 14:21:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=41">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=41">mbox</a>, <a href="#40">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="42"></a><a name="msg42"></a><a href="#42">Message #42</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=42">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=42">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E%0A%20%3C20110908141850.GA7445%40entuzijast.net%3E&In-Reply-To=%3C20110908141850.GA7445%40entuzijast.net%3E&body=On%20Thu%2C%208%20Sep%202011%2016%3A18%3A50%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2003%3A38%3A39PM%20%2B0200%2C%20Raphael%20Hertzog%20wrote%3A%0A%3E%20%3E%20Hi%20Josip%2C%0A%3E%20%3E%20%0A%3E%20%3E%20On%20Thu%2C%2008%20Sep%202011%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20%3E%20Instead%2C%20it%20is%20important%20to%20retain%20the%20age-old%20idea%20that%20the%20rules%20file%20has%0A%3E%20%3E%20%3E%20its%20own%20calling%20convention%20%28an%20API%29%20that%20isn%27t%20linked%20to%20one%20specific%0A%3E%20%3E%20%3E%20implementation%20and%20is%20instead%20properly%20specified%20in%20Debian%20policy%2C%20allowing%0A%3E%20%3E%20%3E%20developers%20some%20common-sense%20leeway%20and%20the%20ability%20to%20adjust%20the%20API%20if%20and%0A%3E%20%3E%20%3E%20when%20necessary.%0A%3E%20%3E%20%0A%3E%20%3E%20The%20API%20is%20not%20the%20only%20thing%20to%20take%20into%20account.%20Using%20anything%20else%0A%3E%20%3E%20than%20make%20is%20unexpected%20for%20most%20other%20developers%20%28some%20of%20them%20who%20might%0A%3E%20%3E%20have%20to%20NMU%20your%20package%20at%20some%20point%29.%0A%3E%20%0A%3E%20I%20agree%2C%20but%20that%20argument%20goes%20both%20ways%20-%20we%20already%20allow%20developers%20to%0A%3E%20use%20obfuscated%20makefiles%2C%20which%20has%20the%20analogous%20potential%20for%20difficulty.%0A%3E%20%0A%3E%20%3E%20%3E%20Heck%2C%20even%20the%20typical%20dh%281%29%20debian%2Frules%20file%20%28so%20typical%20I%20pasted%20it%0A%3E%20%3E%20%3E%20straight%20from%20its%20manual%20page%29%3A%0A%3E%20%3E%20%3E%20%0A%3E%20%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20dh%20%24%40%0A%3E%20%3E%20%3E%20%0A%3E%20%3E%20%3E%20does%20not%20strike%20me%20as%20better%20than%20a%20shell%20script%20such%20as%20the%20one%20used%20by%0A%3E%20%3E%20%3E%20leave%27s%20debian%2Frules%20file%20-%20in%20fact%20it%27s%20seems%20more%20opaque%20and%20needs%20more%0A%3E%20%3E%20%3E%20documentation%2Fknowledge%20to%20figure%20out%20in%20what%20way%20does%20this%20follow%0A%3E%20%3E%20%3E%20the%20rules%20set%20out%20in%20the%20policy.%0A%3E%20%3E%20%0A%3E%20%3E%20Yes%2C%20but%20it%27s%20also%20not%20worse%20than%20having%20to%20read%20the%20sources%20of%20a%20shell%0A%3E%20%3E%20script.%0A%3E%20%0A%3E%20Ahem%2C%20so%20I%20must%20quote%20it%3A%0A%3E%20%0A%3E%20%23%21%2Fbin%2Fsh%20-e%0A%3E%20%0A%3E%20tmp%3D%60pwd%60%2Fdebian%2Fleave%0A%3E%20%0A%3E%20if%20echo%20%24DEB_BUILD_OPTIONS%20%7C%20grep%20-vq%20noopt%3B%20then%0A%3E%20%20%20optflag%3D%22-O2%22%0A%3E%20fi%0A%3E%20%0A%3E%20if%20echo%20%24DEB_BUILD_OPTIONS%20%7C%20grep%20-vq%20nostrip%3B%20then%0A%3E%20%20%20stripflag%3D%22-s%22%0A%3E%20fi%0A%3E%20%0A%3E%20case%20%22%241%22%20in%0A%3E%20%20%20build%29%0A%3E%20%20%20%20%20test%20-f%20leave.c%20%7C%7C%20%7B%20echo%20not%20in%20the%20right%20dir%5C%21%3B%20exit%201%3B%20%7D%0A%3E%20%20%20%20%20test%20-f%20leave%20%7C%7C%20%7B%20cc%20-g%20%24optflag%20-Wall%20%5C%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20-D__COPYRIGHT%5C%28x%5C%29%3D%20-D__RCSID%5C%28x%5C%29%3D%20%5C%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20leave.c%20-o%20leave%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D%0A%3E%20%23%20used%20to%20have%20%27pmake%20CFLAGS%3D%22...%22%20leave%27%20here%2C%20but%20why%3F%0A%3E%20%20%20%20%20%3B%3B%0A%3E%20%20%20clean%29%0A%3E%20%20%20%20%20test%20-f%20leave.c%20%7C%7C%20%7B%20echo%20not%20in%20the%20right%20dir%5C%21%3B%20exit%201%3B%20%7D%0A%3E%20%20%20%20%20test%20%60id%20-u%60%20-eq%200%20%7C%7C%20%7B%20echo%20%22don%27t%20have%20%28pseudo-%29root%21%22%3B%20exit%201%3B%20%7D%0A%3E%20%20%20%20%20rm%20-f%20build-stamp%20leave%20leave.o%20leave.cat1%20debian%2Ffiles%20debian%2Fsubstvars%0A%3E%20%20%20%20%20rm%20-rf%20%24tmp%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 16:18:50 +0200</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 03:38:39PM +0200, Raphael Hertzog wrote: > Hi Josip, > > On Thu, 08 Sep 2011, Josip Rodin wrote: > > Instead, it is important to retain the age-old idea that the rules file has > > its own calling convention (an API) that isn't linked to one specific > > implementation and is instead properly specified in Debian policy, allowing > > developers some common-sense leeway and the ability to adjust the API if and > > when necessary. > > The API is not the only thing to take into account. Using anything else > than make is unexpected for most other developers (some of them who might > have to NMU your package at some point). I agree, but that argument goes both ways - we already allow developers to use obfuscated makefiles, which has the analogous potential for difficulty. > > Heck, even the typical dh(1) debian/rules file (so typical I pasted it > > straight from its manual page): > > > > #!/usr/bin/make -f > > %: > > dh $@ > > > > does not strike me as better than a shell script such as the one used by > > leave's debian/rules file - in fact it's seems more opaque and needs more > > documentation/knowledge to figure out in what way does this follow > > the rules set out in the policy. > > Yes, but it's also not worse than having to read the sources of a shell > script. Ahem, so I must quote it: #!/bin/sh -e tmp=`pwd`/debian/leave if echo $DEB_BUILD_OPTIONS | grep -vq noopt; then optflag="-O2" fi if echo $DEB_BUILD_OPTIONS | grep -vq nostrip; then stripflag="-s" fi case "$1" in build) test -f leave.c || { echo not in the right dir\!; exit 1; } test -f leave || { cc -g $optflag -Wall \ -D__COPYRIGHT$x$= -D__RCSID$x$= \ leave.c -o leave } # used to have 'pmake CFLAGS="..." leave' here, but why? ;; clean) test -f leave.c || { echo not in the right dir\!; exit 1; } test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; } rm -f build-stamp leave leave.o leave.cat1 debian/files debian/substvars rm -rf $tmp ;; binary-arch|binary) test -f leave || $0 build test `id -u` -eq 0 || { echo "don't have (pseudo-)root!"; exit 1; } rm -rf $tmp install -d -m 755 $tmp/usr/bin $tmp/usr/share/man/man1 \ $tmp/DEBIAN $tmp/usr/share/doc/leave install $stripflag -m 755 leave $tmp/usr/bin gzip -c9 leave.1 > $tmp/usr/share/man/man1/leave.1.gz gzip -c9 debian/changelog > $tmp/usr/share/doc/leave/changelog.Debian.gz install -m 644 debian/copyright $tmp/usr/share/doc/leave dpkg-shlibdeps $tmp/usr/bin/leave dpkg-gencontrol -isp -P$tmp chown -R root.root $tmp chmod -R g-ws $tmp dpkg --build $tmp .. ;; binary-indep) # do nothing, successfully! exit 0 ;; *) echo unknown option: $1 exit 1 ;; esac Is the compliance with policy easier to read from the obfuscated makefile example at the top, or from the trivial shell example above? I wouldn't actually definitively answer that question, it's probably a matter of personal vgrep to some extent, but I'm certain the conclusion "makefile syntax, obfuscated or not, is sufficiently better than all others, that all others are hereby forbidden" doesn't make any sense. > And still, this is a Makefile so you can quickly reuse Makefile snippets > that others have been writing to add support for supplementary targets > (like get-orig-source) or even to influence the environment (like the > Makefile snippets that dpkg 1.16.1 is going to provide). Same can work for pretty much any other similar language. If we didn't really need these snippets in all packages so far, it's hard to argue they're relevant as a reason to ban all languages that don't instantly support them. > So I really don't understand why you insist on keeping debian/rules > as a shell script. Moving it one level deeper in the process tree > does not strike me as a big performance/readability loss, certainly not > one worth spending the time of tech-ctte members on such a case. So you want me to satisfy the letter of the policy but break its spirit? :) > > The whole idea that we're changing something in the build-arch handling > > is a nice supporting argument for my idea that we don't have a reason to > > hardcode make - the fact that we control the API means that we are able > > to make this decision, rather than having to adjust to whatever some > > semi-random program does. > > If you ignore all transitions constraints, sure. At the same time, Debian > decided debian/rules must be a Makefile and you're not adjusting to cope. No, "Debian" did not decide to explicitly ban non-shell rules files at any point in time, it was a leftover from a text conversion that never got fixed. The way the Packaging Manual was written was certainly with makefiles in mind, it explicitly said that a rules file is a makefile and used the term "target" and similar. But the description of the API was pretty carefully restricted to the feature set independent of make's intricacies. It remained so until the present day, and it works in practice. So why break it? > Why should you better accept another API design compared to an already > existing policy requirement? I can't parse that sentence, sorry, can you rephrase? -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="43"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 14:57:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=44">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=44">mbox</a>, <a href="#43">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="45"></a>   <strong>Acknowledgement sent</strong> to <code>Raphael Hertzog <hertzog@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 14:57:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=46">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=46">mbox</a>, <a href="#45">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="47"></a><a name="msg47"></a><a href="#47">Message #47</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=47">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=47">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%208%20Sep%202011%2016%3A53%3A01%20%2B0200%20Raphael%20Hertzog%20%3Chertzog%40debian.org%3E%20wrote%3A%0A%3E%20On%20Thu%2C%2008%20Sep%202011%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20%3E%20The%20API%20is%20not%20the%20only%20thing%20to%20take%20into%20account.%20Using%20anything%20else%0A%3E%20%3E%20%3E%20than%20make%20is%20unexpected%20for%20most%20other%20developers%20%28some%20of%20them%20who%20might%0A%3E%20%3E%20%3E%20have%20to%20NMU%20your%20package%20at%20some%20point%29.%0A%3E%20%3E%20%0A%3E%20%3E%20I%20agree%2C%20but%20that%20argument%20goes%20both%20ways%20-%20we%20already%20allow%20developers%20to%0A%3E%20%3E%20use%20obfuscated%20makefiles%2C%20which%20has%20the%20analogous%20potential%20for%20difficulty.%0A%3E%20%0A%3E%20Sure%20enough%2C%20but%20why%20do%20you%20insist%20on%20doing%20as%20badly%20as%20some%20other%20are%0A%3E%20doing%3F%0A%3E%20%0A%3E%20On%20my%20side%2C%20I%27m%20not%20doing%20poor%20work%20just%20because%20others%20have%20done%20so%20and%0A%3E%20nobody%20complained%20yet.%20%3A-%29%0A%3E%20%0A%3E%20%3E%20%3E%20Yes%2C%20but%20it%27s%20also%20not%20worse%20than%20having%20to%20read%20the%20sources%20of%20a%20shell%0A%3E%20%3E%20%3E%20script.%0A%3E%20%3E%20%0A%3E%20%3E%20Ahem%2C%20so%20I%20must%20quote%20it%3A%0A%3E%20%0A%3E%20I%20don%27t%20think%20it%20changes%20my%20point%20of%20view.%20I%20know%20way%20better%20the%20default%0A%3E%20behaviour%20of%20debhelper%20than%20the%20resulting%20behaviour%20of%20your%20package.%0A%3E%20%0A%3E%20And%20I%20know%20debhelper%20allows%20for%20massive%20changes%20that%20would%20not%20be%20possible%0A%3E%20if%20all%20packages%20were%20doing%20like%20you.%0A%3E%20%0A%3E%20On%20the%20contrary%2C%20I%20see%20that%20your%20package%20does%20nothing%20fancy%20that%20could%0A%3E%20justify%20the%20use%20of%20something%20else%20than%20what%20is%20the%20de-facto%20standard.%0A%3E%20Your%20script%20is%20trivial%20to%20convert%20to%20a%20Makefile.%0A%3E%20%0A%3E%20%3E%20Is%20the%20compliance%20with%20policy%20easier%20to%20read%20from%20the%20obfuscated%20makefile%0A%3E%20%3E%20example%20at%20the%20top%2C%20or%20from%20the%20trivial%20shell%20example%20above%3F%0A%3E%20%0A%3E%20It%20depends%20on%20one%27s%20background.%20A%20casual%20DD%20knows%20debhelper%20way%20better%0A%3E%20than%20a%20custom%20shell%20script.%0A%3E%20%0A%3E%20It%27s%20quite%20possible%20to%20you%20missed%20something%20in%20your%20package%20and%20it%27s%20not%0A%3E%20easy%20to%20verify%20it%20just%20from%20reading%20the%20rules%20files.%20If%20you%20use%20debhelper%2C%0A%3E%20you%20know%20that%20all%20the%20cases%20that%20can%20be%20automated%20are%20already%20taken%20care%0A%3E%20of.%20So%20I%27m%20more%20confident%20in%20the%20policy%20compliance%20of%20a%204-line%20dh-based%0A%3E%20rules%20file%20than%20of%20your%20schell%20script.%0A%3E%20%0A%3E%20%3E%20%3E%20And%20still%2C%20this%20is%20a%20Makefile%20so%20you%20can%20quickly%20reuse%20Makefile%20snippets%0A%3E%20%3E%20%3E%20that%20others%20have%20been%20writing%20to%20add%20support%20for%20supplementary%20targets%0A%3E%20%3E%20%3E%20%28like%20get-orig-source%29%20or%20even%20to%20influence%20the%20environment%20%28like%20the%0A%3E%20%3E%20%3E%20Makefile%20snippets%20that%20dpkg%201.16.1%20is%20going%20to%20provide%29.%0A%3E%20%3E%20%0A%3E%20%3E%20Same%20can%20work%20for%20pretty%20much%20any%20other%20similar%20language.%0A%3E%20%0A%3E%20Except%20that%20by%20standardizing%20on%20make%20we%20avoid%20to%20have%20to%20duplicate%0A%3E%20those%20things%20for%20multiple%20languages%21%0A%3E%20%0A%3E%20%3E%20%3E%20So%20I%20really%20don%27t%20understand%20why%20you%20insist%20on%20keeping%20debian%2Frules%0A%3E%20%3E%20%3E%20as%20a%20shell%20script.%20Moving%20it%20one%20level%20deeper%20in%20the%20process%20tree%0A%3E%20%3E%20%3E%20does%20not%20strike%20me%20as%20a%20big%20performance%2Freadability%20loss%2C%20certainly%20not%0A%3E%20%3E%20%3E%20one%20worth%20spending%20the%20time%20of%20tech-ctte%20members%20on%20such%20a%20case.%0A%3E%20%3E%20%0A%3E%20%3E%20So%20you%20want%20me%20to%20satisfy%20the%20letter%20of%20the%20policy%20but%20break%20its%20spirit%3F%20%3A%29%0A%3E%20%0A%3E%20You%20seem%20to%20be%20arguing%20that%20you%27re%20following%20its%20spirit%20but%20not%20the%20letter%0A%3E%20of%20it.%20So%20yes%2C%20please%20follow%20the%20letter%20of%20it%20in%20whatever%20way%20that%20you%20believe%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E%0A%20%3C20110908141850.GA7445%40entuzijast.net%3E%0A%20%3C20110908145301.GB24664%40rivendell.home.ouaza.com%3E&In-Reply-To=%3C20110908145301.GB24664%40rivendell.home.ouaza.com%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=hertzog%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 16:53:01 +0200</div> </div> <pre class="message">On Thu, 08 Sep 2011, Josip Rodin wrote: > > The API is not the only thing to take into account. Using anything else > > than make is unexpected for most other developers (some of them who might > > have to NMU your package at some point). > > I agree, but that argument goes both ways - we already allow developers to > use obfuscated makefiles, which has the analogous potential for difficulty. Sure enough, but why do you insist on doing as badly as some other are doing? On my side, I'm not doing poor work just because others have done so and nobody complained yet. :-) > > Yes, but it's also not worse than having to read the sources of a shell > > script. > > Ahem, so I must quote it: I don't think it changes my point of view. I know way better the default behaviour of debhelper than the resulting behaviour of your package. And I know debhelper allows for massive changes that would not be possible if all packages were doing like you. On the contrary, I see that your package does nothing fancy that could justify the use of something else than what is the de-facto standard. Your script is trivial to convert to a Makefile. > Is the compliance with policy easier to read from the obfuscated makefile > example at the top, or from the trivial shell example above? It depends on one's background. A casual DD knows debhelper way better than a custom shell script. It's quite possible to you missed something in your package and it's not easy to verify it just from reading the rules files. If you use debhelper, you know that all the cases that can be automated are already taken care of. So I'm more confident in the policy compliance of a 4-line dh-based rules file than of your schell script. > > And still, this is a Makefile so you can quickly reuse Makefile snippets > > that others have been writing to add support for supplementary targets > > (like get-orig-source) or even to influence the environment (like the > > Makefile snippets that dpkg 1.16.1 is going to provide). > > Same can work for pretty much any other similar language. Except that by standardizing on make we avoid to have to duplicate those things for multiple languages! > > So I really don't understand why you insist on keeping debian/rules > > as a shell script. Moving it one level deeper in the process tree > > does not strike me as a big performance/readability loss, certainly not > > one worth spending the time of tech-ctte members on such a case. > > So you want me to satisfy the letter of the policy but break its spirit? :) You seem to be arguing that you're following its spirit but not the letter of it. So yes, please follow the letter of it in whatever way that you believe is coherent with the spirit of Debian. > No, "Debian" did not decide to explicitly ban non-shell rules files at any > point in time, it was a leftover from a text conversion that never got > fixed. I'm convinced this change would have been adopted even if it had been proposed in a explicit manner. > It remained so until the present day, and it works in practice. So why > break it? Why make dozens of developers lose time on this issue when it takes 5 minutes to convert your shell script and when you have already shown that this rule is not restricting the flexibility we already have ? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ <a href="http://RaphaelHertzog.com">http://RaphaelHertzog.com</a> (English) ▶ <a href="http://RaphaelHertzog.fr">http://RaphaelHertzog.fr</a> (Français) </pre> <div class="infmessage"><hr><p> <a name="48"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 16:09:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=49">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=49">mbox</a>, <a href="#48">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="50"></a>   <strong>Acknowledgement sent</strong> to <code>Bdale Garbee <bdale@gag.com></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 16:09:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=51">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=51">mbox</a>, <a href="#50">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="52"></a><a name="msg52"></a><a href="#52">Message #52</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=52">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=52">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Thu%2C%2008%20Sep%202011%2010%3A07%3A21%20-0600%20Bdale%20Garbee%20%3Cbdale%40gag.com%3E%20wrote%3A%0A%3E%20On%20Thu%2C%208%20Sep%202011%2016%3A18%3A50%20%2B0200%2C%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20%3E%20%3E%20If%20you%20ignore%20all%20transitions%20constraints%2C%20sure.%20At%20the%20same%20time%2C%20Debian%0A%3E%20%3E%20%3E%20decided%20debian%2Frules%20must%20be%20a%20Makefile%20and%20you%27re%20not%20adjusting%20to%20cope.%0A%3E%20%3E%20%0A%3E%20%3E%20No%2C%20%22Debian%22%20did%20not%20decide%20to%20explicitly%20ban%20non-shell%20rules%20files%20at%20any%0A%3E%20%3E%20point%20in%20time%2C%20it%20was%20a%20leftover%20from%20a%20text%20conversion%20that%20never%20got%0A%3E%20%3E%20fixed.%0A%3E%20%0A%3E%20You%20can%20say%20that%20and%20it%20may%20be%20literally%20true%2C%20but%20my%20own%20interpretation%0A%3E%20of%20history%20is%20that%20we%20never%20anticipated%20debian%2Frules%20being%20anything%0A%3E%20%2Aother%2A%20than%20a%20makefile%20and%20thus%20an%20unintended%20loophole%20existed%20that%0A%3E%20eventually%20got%20closed.%0A%3E%20%0A%3E%20While%20I%20understand%20and%20appreciate%20your%20arguments%2C%20I%20personally%20see%20no%0A%3E%20practical%20value%20in%20having%20debian%2Frules%20be%20anything%20other%20than%20a%0A%3E%20makefile%2C%20and%20lots%20of%20reasons%20that%20having%20it%20always%20be%20a%20makefile%20is%0A%3E%20useful.%20%0A%3E%20%0A%3E%20Bdale%0A&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%20%3C20110908075940.GA2168%40entuzijast.net%3E%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%20%3C20110908123815.GA13055%40entuzijast.net%3E%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E%20%3C20110908141850.GA7445%40entuzijast.net%3E%0A%20%3C87zkifdnly.fsf%40gag.com%3E&In-Reply-To=%3C87zkifdnly.fsf%40gag.com%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=bdale%40gag.com" alt=""> <div class="header"><span class="headerfield">From:</span> Bdale Garbee <bdale@gag.com></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net>, 640874@bugs.debian.org, Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 08 Sep 2011 10:07:21 -0600</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=52">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">On Thu, 8 Sep 2011 16:18:50 +0200, Josip Rodin <joy@debbugs.entuzijast.net> wrote: > > If you ignore all transitions constraints, sure. At the same time, Debian > > decided debian/rules must be a Makefile and you're not adjusting to cope. > > No, "Debian" did not decide to explicitly ban non-shell rules files at any > point in time, it was a leftover from a text conversion that never got > fixed. You can say that and it may be literally true, but my own interpretation of history is that we never anticipated debian/rules being anything *other* than a makefile and thus an unintended loophole existed that eventually got closed. While I understand and appreciate your arguments, I personally see no practical value in having debian/rules be anything other than a makefile, and lots of reasons that having it always be a makefile is useful. Bdale </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;msg=52">Message part 2</a> (application/pgp-signature, inline)]</pre> <div class="infmessage"><hr><p> <a name="53"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 08 Sep 2011 23:21:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=54">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=54">mbox</a>, <a href="#53">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="55"></a>   <strong>Acknowledgement sent</strong> to <code>Russ Allbery <rra@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 08 Sep 2011 23:21:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=56">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=56">mbox</a>, <a href="#55">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="57"></a><a name="msg57"></a><a href="#57">Message #57</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=57">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=57">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%2008%20Sep%202011%2016%3A18%3A34%20-0700%20Russ%20Allbery%20%3Crra%40debian.org%3E%20wrote%3A%0A%3E%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%20It%20was%20just%20an%20arbitrary%20conversion%20of%20a%20single%20%22is%22%20to%20%22must%20be%22%20%28in%20an%0A%3E%20%3E%20unrelated%20let%27s-use-consistent-RFC-like-wording%20drive%29%20that%20went%0A%3E%20%3E%20unchecked.%0A%3E%20%0A%3E%20I%20wanted%20to%20mention%20here%20that%20this%20didn%27t%20just%20suddenly%20happen%20as%20a%20result%0A%3E%20of%20the%20existing%20Policy%20wording%20without%20any%20further%20discussion.%20%20There%20were%0A%3E%20several%20discussions%20over%20a%20few%20months%20about%20this%20particular%20Lintian%20tag%2C%0A%3E%20particularly%20since%20it%20kept%20coming%20up%20in%20the%20build-arch%20discussion%2C%20and%0A%3E%20there%20was%20some%20consensus%20on%20debian-devel%20before%20it%20was%20added%20to%20the%0A%3E%20ftp-master%20reject%20list.%20%20Part%20of%20that%20discussion%20was%20specifically%20around%0A%3E%20whether%20debian%2Frules%20should%20be%20viewed%20as%20an%20abstract%20API%20or%20whether%20the%0A%3E%20fact%20that%20it%27s%20a%20makefile%20is%20an%20exposed%20part%20of%20the%20API%2C%20and%20there%20was%20at%0A%3E%20least%20one%20advocate%20of%20having%20it%20instead%20be%20an%20abstract%20API.%20%20My%20read%20on%0A%3E%20the%20discussion%20was%20that%20the%20consensus%20went%20the%20other%20way.%0A%3E%20%0A%3E%20I%20agree%20that%20this%20was%20not%20primarily%20a%20technical%20decision.%20%20Rather%2C%20it%20was%0A%3E%20a%20decision%20around%20unity%20of%20practice%20aiming%20towards%20simplifying%20our%0A%3E%20packaging%20methods%20%28which%20in%20the%20past%20have%20been%20divergent%20to%20the%20degree%0A%3E%20that%20it%27s%20caused%20some%20problems%29.%20%20We%20don%27t%20want%20to%20eliminate%20diversity%0A%3E%20that%20people%20find%20helpful%20to%20get%20their%20work%20done%20or%20that%27s%20a%20widespread%0A%3E%20difference%20of%20taste%20among%20packagers%2C%20such%20as%20the%20dh%20vs.%20CDBS%20discussion.%0A%3E%20But%20no%20one%20seemed%20to%20be%20using%20a%20non-makefile%20debian%2Frules%20to%20that%20purpose%3B%0A%3E%20leave%20was%20the%20only%20package%20that%20didn%27t%20have%20a%20makefile%20debian%2Frules%2C%20and%0A%3E%20even%20all%20your%20other%20packages%20were%20using%20a%20makefile%2C%20so%20it%20didn%27t%20seem%20to%0A%3E%20be%20a%20decision%20on%20your%20part%20to%20use%20a%20mechanism%20that%20you%20found%20generally%0A%3E%20better.%0A%3E%20%0A%3E%20%28I%20don%27t%20recall%20if%20anyone%20tried%20to%20loop%20you%20into%20that%20discussion%3B%20if%20that%0A%3E%20didn%27t%20happen%2C%20that%20was%20a%20flaw%20in%20that%20discussion%20process%20to%20be%20sure.%29%0A%3E%20%0A%3E%20The%20conclusion%20at%20the%20time%2C%20at%20least%20by%20my%20reading%20of%20the%20discussion%2C%20was%0A%3E%20that%20this%20was%20a%20bit%20of%20flexibility%20that%20we%20didn%27t%20need%20and%20therefore%0A%3E%20probably%20should%20eliminate%20in%20the%20name%20of%20simplifying%20the%20possible%0A%3E%20implementation%20choices%2C%20rather%20than%20changing%20the%20Policy%20wording%20to%20allow%0A%3E%20it.%0A%3E%20%0A%3E%20--%20%0A%3E%20Russ%20Allbery%20%28rra%40debian.org%29%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Chttp%3A%2F%2Fwww.eyrie.org%2F~eagle%2F%3E%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&In-Reply-To=%3C87d3fak4hh.fsf%40windlord.stanford.edu%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C20110908075940.GA2168%40entuzijast.net%3E%0A%09%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%09%3C20110908095033.GA491%40riva.dynamic.greenend.org.uk%3E%0A%09%3C20110908125500.GA17694%40entuzijast.net%3E%0A%20%3C87d3fak4hh.fsf%40windlord.stanford.edu%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=rra%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org, Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 08 Sep 2011 16:18:34 -0700</div> </div> <pre class="message">Josip Rodin <joy@debbugs.entuzijast.net> writes: > It was just an arbitrary conversion of a single "is" to "must be" (in an > unrelated let's-use-consistent-RFC-like-wording drive) that went > unchecked. I wanted to mention here that this didn't just suddenly happen as a result of the existing Policy wording without any further discussion. There were several discussions over a few months about this particular Lintian tag, particularly since it kept coming up in the build-arch discussion, and there was some consensus on debian-devel before it was added to the ftp-master reject list. Part of that discussion was specifically around whether debian/rules should be viewed as an abstract API or whether the fact that it's a makefile is an exposed part of the API, and there was at least one advocate of having it instead be an abstract API. My read on the discussion was that the consensus went the other way. I agree that this was not primarily a technical decision. Rather, it was a decision around unity of practice aiming towards simplifying our packaging methods (which in the past have been divergent to the degree that it's caused some problems). We don't want to eliminate diversity that people find helpful to get their work done or that's a widespread difference of taste among packagers, such as the dh vs. CDBS discussion. But no one seemed to be using a non-makefile debian/rules to that purpose; leave was the only package that didn't have a makefile debian/rules, and even all your other packages were using a makefile, so it didn't seem to be a decision on your part to use a mechanism that you found generally better. (I don't recall if anyone tried to loop you into that discussion; if that didn't happen, that was a flaw in that discussion process to be sure.) The conclusion at the time, at least by my reading of the discussion, was that this was a bit of flexibility that we didn't need and therefore probably should eliminate in the name of simplifying the possible implementation choices, rather than changing the Policy wording to allow it. -- Russ Allbery (rra@debian.org) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>> </pre> <div class="infmessage"><hr><p> <a name="58"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 00:51:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=59">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=59">mbox</a>, <a href="#58">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="60"></a>   <strong>Acknowledgement sent</strong> to <code>Colin Watson <cjwatson@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 00:51:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=61">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=61">mbox</a>, <a href="#60">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="62"></a><a name="msg62"></a><a href="#62">Message #62</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=62">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=62">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110909004537.GM2560%40riva.dynamic.greenend.org.uk%3E&In-Reply-To=%3C20110909004537.GM2560%40riva.dynamic.greenend.org.uk%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Fri%2C%209%20Sep%202011%2001%3A45%3A37%20%2B0100%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2002%3A38%3A15PM%20%2B0200%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20But%2C%20to%20return%20to%20the%20former%20idea%20of%20arguing%20for%20flexibility%20for%20just%20one%0A%3E%20%3E%20moment%20-%20that%27s%20moot%20because%20of%20another%20reason%20-%20we%20%2Aalready%2A%20allow%20a%0A%3E%20%3E%20near-infinite%20amount%20of%20abuse%20through%20flexibility%2C%20because%20you%20can%20make%20a%0A%3E%20%3E%20makefile%20fork%20another%20program%20and%20do%20whatever%20afterwards.%20It%20would%20abide%20by%0A%3E%20%3E%20the%20letter%20of%20the%20rules%2C%20and%20people%20have%20suggested%20to%20me%20that%20I%20do%20that%2C%20but%0A%3E%20%3E%20I%20don%27t%20think%20that%20would%20be%20in%20line%20with%20the%20spirit%20of%20the%20rules%2C%20which%0A%3E%20%3E%20provide%20a%20nice%2C%20clean%20description%20of%20what%20gets%20done%20for%20which%20specified%0A%3E%20%3E%20action%20or%20variable%2C%20so%20the%20code%20should%20roughly%20match%20such%20a%20description%0A%3E%20%3E%20without%20a%20lot%20of%20necessary%20overhead.%0A%3E%20%3E%20%0A%3E%20%3E%20Heck%2C%20even%20the%20typical%20dh%281%29%20debian%2Frules%20file%20%28so%20typical%20I%20pasted%20it%0A%3E%20%3E%20straight%20from%20its%20manual%20page%29%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%3E%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20dh%20%24%40%0A%3E%20%3E%20%0A%3E%20%3E%20does%20not%20strike%20me%20as%20better%20than%20a%20shell%20script%20such%20as%20the%20one%20used%20by%0A%3E%20%3E%20leave%27s%20debian%2Frules%20file%20-%20in%20fact%20it%27s%20seems%20more%20opaque%20and%20needs%20more%0A%3E%20%3E%20documentation%2Fknowledge%20to%20figure%20out%20in%20what%20way%20does%20this%20follow%0A%3E%20%3E%20the%20rules%20set%20out%20in%20the%20policy.%0A%3E%20%0A%3E%20In%20practice%2C%20though%2C%20this%20is%20the%20only%20case%20I%27ve%20heard%20of%20like%20this%2C%20and%0A%3E%20it%27s%20balanced%20by%20a%20few%20points%3A%0A%3E%20%0A%3E%20%20%20%2A%2038%25%20of%20the%20source%20packages%20in%20Debian%20unstable%20use%20dh%281%29.%20%20While%0A%3E%20%20%20%20%20popularity%20isn%27t%20always%20the%20best%20measure%2C%20at%20this%20point%2C%20there%20is%0A%3E%20%20%20%20%20clearly%20no%20shortage%20of%20developers%20who%20understand%20dh%281%29%2C%20find%20it%0A%3E%20%20%20%20%20straightforward%20to%20inspect%20and%20modify%2C%20and%20could%20be%20roped%20in%20for%0A%3E%20%20%20%20%20assistance%20if%20need%20be.%0A%3E%20%0A%3E%20%20%20%2A%20debhelper%20in%20general%2C%20including%20dh%281%29%2C%20has%20an%20excellent%20track%20record%0A%3E%20%20%20%20%20at%20keeping%20up%20with%20policy%20changes%20and%20helping%20packages%20to%20follow%0A%3E%20%20%20%20%20policy%2C%20and%20nowadays%20it%20very%20often%20does%20a%20better%20job%20than%20people%0A%3E%20%20%20%20%20trying%20to%20keep%20up%20by%20hand.%20%20The%20first-glance%20opaqueness%20of%20the%20tiny%0A%3E%20%20%20%20%20rules%20style%20seems%20to%20have%20good%20results%20in%20practice.%0A%3E%20%0A%3E%20%20%20%2A%20While%20it%27s%20true%20that%20make%20is%20largely%20delegating%20responsibility%20to%0A%3E%20%20%20%20%20another%20program%20here%2C%20it%27s%20a%20common%20program%20used%20by%20many%20packages%2C%0A%3E%20%20%20%20%20and%20so%20serves%20to%20consolidate%20a%20lot%20of%20boring%20common%20code%20which%20is%20a%0A%3E%20%20%20%20%20fairly%20standard%20software%20virtue.%20%20I%27d%20be%20hard-pressed%20to%20codify%0A%3E%20%20%20%20%20this%2C%20but%20that%20does%20seem%20different%20in%20kind%20from%20forking%20a%20secondary%0A%3E%20%20%20%20%20rules%20implementation%20local%20to%20a%20single%20source%20package%20simply%20for%20the%0A%3E%20%20%20%20%20purpose%20of%20switching%20language.%0A%3E%20%0A%3E%20%3E%20Instead%2C%20it%20is%20important%20to%20retain%20the%20age-old%20idea%20that%20the%20rules%20file%20has%0A%3E%20%3E%20its%20own%20calling%20convention%20%28an%20API%29%20that%20isn%27t%20linked%20to%20one%20specific%0A%3E%20%3E%20implementation%20and%20is%20instead%20properly%20specified%20in%20Debian%20policy%2C%20allowing%0A%3E%20%3E%20developers%20some%20common-sense%20leeway%20and%20the%20ability%20to%20adjust%20the%20API%20if%20and%0A%3E%20%3E%20when%20necessary.%0A%3E%20%5B...%5D%0A%3E%20%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2010%3A43%3A44AM%20%2B0100%2C%20Colin%20Watson%20wrote%3A%0A%3E%20%3E%20%3E%20I%20can%20provide%20a%20concrete%20practical%20reason%20for%20requiring%20make%20as%20the%0A%3E%20%3E%20%3E%20implementation%20language%3A%20at%20least%20one%2C%20probably%20two%2C%20of%20the%20options%20for%0A%3E%20%3E%20%3E%20build-arch%20handling%0A%3E%20%3E%20%3E%20%28http%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D629385%2393%29%20require%0A%3E%20%3E%20%3E%20debian%2Frules%20to%20be%20a%20Makefile.%20%20The%20leave%20package%20might%20be%20able%20to%20get%0A%3E%20%3E%20%3E%20away%20with%20a%20little%20bit%20more%20if%20its%20exit%20code%20matched%20that%20of%20make%20for%0A%3E%20%3E%20%3E%20nonexisting%20targets%2C%20mentioned%20in%20policy%204.9%3B%20however%2C%20it%20exits%201%20rather%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=cjwatson%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org, Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Fri, 9 Sep 2011 01:45:37 +0100</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 02:38:15PM +0200, Josip Rodin wrote: > But, to return to the former idea of arguing for flexibility for just one > moment - that's moot because of another reason - we *already* allow a > near-infinite amount of abuse through flexibility, because you can make a > makefile fork another program and do whatever afterwards. It would abide by > the letter of the rules, and people have suggested to me that I do that, but > I don't think that would be in line with the spirit of the rules, which > provide a nice, clean description of what gets done for which specified > action or variable, so the code should roughly match such a description > without a lot of necessary overhead. > > Heck, even the typical dh(1) debian/rules file (so typical I pasted it > straight from its manual page): > > #!/usr/bin/make -f > %: > dh $@ > > does not strike me as better than a shell script such as the one used by > leave's debian/rules file - in fact it's seems more opaque and needs more > documentation/knowledge to figure out in what way does this follow > the rules set out in the policy. In practice, though, this is the only case I've heard of like this, and it's balanced by a few points: * 38% of the source packages in Debian unstable use dh(1). While popularity isn't always the best measure, at this point, there is clearly no shortage of developers who understand dh(1), find it straightforward to inspect and modify, and could be roped in for assistance if need be. * debhelper in general, including dh(1), has an excellent track record at keeping up with policy changes and helping packages to follow policy, and nowadays it very often does a better job than people trying to keep up by hand. The first-glance opaqueness of the tiny rules style seems to have good results in practice. * While it's true that make is largely delegating responsibility to another program here, it's a common program used by many packages, and so serves to consolidate a lot of boring common code which is a fairly standard software virtue. I'd be hard-pressed to codify this, but that does seem different in kind from forking a secondary rules implementation local to a single source package simply for the purpose of switching language. > Instead, it is important to retain the age-old idea that the rules file has > its own calling convention (an API) that isn't linked to one specific > implementation and is instead properly specified in Debian policy, allowing > developers some common-sense leeway and the ability to adjust the API if and > when necessary. [...] > On Thu, Sep 08, 2011 at 10:43:44AM +0100, Colin Watson wrote: > > I can provide a concrete practical reason for requiring make as the > > implementation language: at least one, probably two, of the options for > > build-arch handling > > (<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93</a>) require > > debian/rules to be a Makefile. The leave package might be able to get > > away with a little bit more if its exit code matched that of make for > > nonexisting targets, mentioned in policy 4.9; however, it exits 1 rather > > than 2 in this case. I realise that this may be because you are unable > > to upload new versions with the shell implementation. > > Implementing a return code handler seems perfectly sensible. The idea that > programs can return a variety of codes to indicate a variety of conditions > is both ancient and pervasive. Even testing the result of make -qn is > basically repeating the same thing, so why add an additional dependency? Conflating "is this option supported" with execution is not without problems. Here's a simple example of a case where testing by execution gives the wrong answer; I haven't made it entirely plausible, but 'test' is a common enough command that I'm sure it's easy to imagine more realistic versions: #! /usr/bin/make -f build-arch: # we forgot the closing ] [ foo Sure, in the specific case of build-arch it happens that this probably fails harmlessly, but I at least find that non-obvious enough that I have to think about it. Without wishing to get into the make vs. Build-Options debate in this bug report, since that's a matter for #629385, this suggests to me that there is at least room for an interface that queries capabilities without actually executing code from the targets in question [1], and that exit codes aren't that interface. I have some sympathy with the core argument that the interface is 'debian/rules build' etc. rather than 'make -f debian/rules build', but there just doesn't seem that much to be gained in practice from lifting the restriction again, and potentially some interesting things to lose. [1] 'make -qn' isn't *quite* that; it still executes $(shell) commands, which means that Lintian can't use it. However, the fixed implementation language is still of benefit to Lintian, since it can parse debian/rules to test whether required and recommended targets are present. Regards, -- Colin Watson [cjwatson@debian.org] </pre> <div class="infmessage"><hr><p> <a name="63"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 02:18:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=64">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=64">mbox</a>, <a href="#63">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="65"></a>   <strong>Acknowledgement sent</strong> to <code>Joey Hess <joeyh@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 02:18:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=66">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=66">mbox</a>, <a href="#65">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="67"></a><a name="msg67"></a><a href="#67">Message #67</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=67">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=67">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Thu%2C%208%20Sep%202011%2022%3A14%3A54%20-0400%20Joey%20Hess%20%3Cjoeyh%40debian.org%3E%20wrote%3A%0A%3E%20Colin%20Watson%20wrote%3A%0A%3E%20%3E%20%20%20%2A%20While%20it%27s%20true%20that%20make%20is%20largely%20delegating%20responsibility%20to%0A%3E%20%3E%20%20%20%20%20another%20program%20here%2C%20it%27s%20a%20common%20program%20used%20by%20many%20packages%2C%0A%3E%20%3E%20%20%20%20%20and%20so%20serves%20to%20consolidate%20a%20lot%20of%20boring%20common%20code%20which%20is%20a%0A%3E%20%3E%20%20%20%20%20fairly%20standard%20software%20virtue.%20%20I%27d%20be%20hard-pressed%20to%20codify%0A%3E%20%3E%20%20%20%20%20this%2C%20but%20that%20does%20seem%20different%20in%20kind%20from%20forking%20a%20secondary%0A%3E%20%3E%20%20%20%20%20rules%20implementation%20local%20to%20a%20single%20source%20package%20simply%20for%20the%0A%3E%20%3E%20%20%20%20%20purpose%20of%20switching%20language.%0A%3E%20%0A%3E%20If%20it%20helps%2C%20while%20I%20used%20to%20agree%20with%20Josip%2C%20I%20changed%20my%20mind%2C%20and%20dh%0A%3E%20is%20actually%20what%20changed%20it.%20While%20dh%20subverts%20policy%20to%20a%20certian%0A%3E%20extent%2C%20policy%20required%20it%20be%20used%20in%20the%20context%20of%20a%20makefile%2C%20and%0A%3E%20this%20led%20to%20it%20using%20the%20makefile%20for%20configuration%20via%20override%0A%3E%20targets%2C%20which%20was%20the%20single%20most%20important%20development%20in%20dh%27s%20evolution.%0A%3E%20If%20debian%2Frules%20had%20not%20remained%20a%20makefile%2C%20that%20would%20not%20have%20been%0A%3E%20possible%2C%20and%20dh%20would%20have%20a%20more%20complex%20and%20less%20flexible%20configuration.%0A%3E%20%0A%3E%20Since%20dh%20is%20a%20common%20idiom%2C%20it%27s%20not%20particularly%20confusing%20to%20do%20this%2C%20now%3A%0A%3E%20%0A%3E%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%25%3A%0A%3E%20%09debian%2Fmyscript%20%24%40%0A%3E%20%0A%3E%20Which%20is%20probably%20the%20simplest%20way%20to%20bring%20leave%20into%20policy%20compliance.%0A%3E%20%0A%3E%20--%20%0A%3E%20see%20shy%20jo%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&In-Reply-To=%3C20110909021454.GA16496%40gnu.kitenet.net%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110909004537.GM2560%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110909021454.GA16496%40gnu.kitenet.net%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joeyh%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Joey Hess <joeyh@debian.org></div> <div class="header"><span class="headerfield">To:</span> Colin Watson <cjwatson@debian.org>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Josip Rodin <joy@debbugs.entuzijast.net>, Niels Thykier <niels@thykier.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 8 Sep 2011 22:14:54 -0400</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=67">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">Colin Watson wrote: > * While it's true that make is largely delegating responsibility to > another program here, it's a common program used by many packages, > and so serves to consolidate a lot of boring common code which is a > fairly standard software virtue. I'd be hard-pressed to codify > this, but that does seem different in kind from forking a secondary > rules implementation local to a single source package simply for the > purpose of switching language. If it helps, while I used to agree with Josip, I changed my mind, and dh is actually what changed it. While dh subverts policy to a certian extent, policy required it be used in the context of a makefile, and this led to it using the makefile for configuration via override targets, which was the single most important development in dh's evolution. If debian/rules had not remained a makefile, that would not have been possible, and dh would have a more complex and less flexible configuration. Since dh is a common idiom, it's not particularly confusing to do this, now: #!/usr/bin/make -f %: debian/myscript $@ Which is probably the simplest way to bring leave into policy compliance. -- see shy jo </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;filename=signature.asc;msg=67">signature.asc</a> (application/pgp-signature, inline)]</pre> <div class="infmessage"><hr><p> <a name="68"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 07:03:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=69">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=69">mbox</a>, <a href="#68">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="70"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 07:03:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=71">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=71">mbox</a>, <a href="#70">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="72"></a><a name="msg72"></a><a href="#72">Message #72</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=72">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=72">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E%0A%20%3C20110908141850.GA7445%40entuzijast.net%3E%0A%20%3C20110908145301.GB24664%40rivendell.home.ouaza.com%3E%0A%20%3C20110909065800.GA19064%40entuzijast.net%3E&In-Reply-To=%3C20110909065800.GA19064%40entuzijast.net%3E&body=On%20Fri%2C%209%20Sep%202011%2008%3A58%3A00%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2004%3A53%3A01PM%20%2B0200%2C%20Raphael%20Hertzog%20wrote%3A%0A%3E%20%3E%20%3E%20%3E%20And%20still%2C%20this%20is%20a%20Makefile%20so%20you%20can%20quickly%20reuse%20Makefile%20snippets%0A%3E%20%3E%20%3E%20%3E%20that%20others%20have%20been%20writing%20to%20add%20support%20for%20supplementary%20targets%0A%3E%20%3E%20%3E%20%3E%20%28like%20get-orig-source%29%20or%20even%20to%20influence%20the%20environment%20%28like%20the%0A%3E%20%3E%20%3E%20%3E%20Makefile%20snippets%20that%20dpkg%201.16.1%20is%20going%20to%20provide%29.%0A%3E%20%3E%20%3E%20%0A%3E%20%3E%20%3E%20Same%20can%20work%20for%20pretty%20much%20any%20other%20similar%20language.%0A%3E%20%3E%20%0A%3E%20%3E%20Except%20that%20by%20standardizing%20on%20make%20we%20avoid%20to%20have%20to%20duplicate%0A%3E%20%3E%20those%20things%20for%20multiple%20languages%21%0A%3E%20%0A%3E%20OTOH%2C%20if%20you%20actually%20want%20to%20that%20stuff%20from%20e.g.%20a%20Python%20debian%2Frules%0A%3E%20file%2C%20you%20should%20be%20able%20to%20simply%20run%0A%3E%20%0A%3E%20%09make%20-f%20%2Fusr%2Fshare%2Fcommon%2Fstuff.mk%20get-orig-source%0A%3E%20%0A%3E%20%3F%20%3A%29%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Fri, 9 Sep 2011 08:58:00 +0200</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 04:53:01PM +0200, Raphael Hertzog wrote: > > > And still, this is a Makefile so you can quickly reuse Makefile snippets > > > that others have been writing to add support for supplementary targets > > > (like get-orig-source) or even to influence the environment (like the > > > Makefile snippets that dpkg 1.16.1 is going to provide). > > > > Same can work for pretty much any other similar language. > > Except that by standardizing on make we avoid to have to duplicate > those things for multiple languages! OTOH, if you actually want to that stuff from e.g. a Python debian/rules file, you should be able to simply run make -f /usr/share/common/stuff.mk get-orig-source ? :) -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="73"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 07:03:12 GMT) (<a href="bugreport.cgi?bug=640874;msg=74">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=74">mbox</a>, <a href="#73">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="75"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 07:03:12 GMT) (<a href="bugreport.cgi?bug=640874;msg=76">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=76">mbox</a>, <a href="#75">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="77"></a><a name="msg77"></a><a href="#77">Message #77</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=77">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=77">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908095033.GA491%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908125500.GA17694%40entuzijast.net%3E%0A%20%3C87d3fak4hh.fsf%40windlord.stanford.edu%3E%0A%20%3C20110909070115.GB19064%40entuzijast.net%3E&In-Reply-To=%3C20110909070115.GB19064%40entuzijast.net%3E&body=On%20Fri%2C%209%20Sep%202011%2009%3A01%3A15%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2004%3A18%3A34PM%20-0700%2C%20Russ%20Allbery%20wrote%3A%0A%3E%20%3E%20%28I%20don%27t%20recall%20if%20anyone%20tried%20to%20loop%20you%20into%20that%20discussion%3B%20if%20that%0A%3E%20%3E%20didn%27t%20happen%2C%20that%20was%20a%20flaw%20in%20that%20discussion%20process%20to%20be%20sure.%29%0A%3E%20%0A%3E%20Nope%2C%20sorry%2C%20I%20missed%20that.%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Fri, 9 Sep 2011 09:01:15 +0200</div> </div> <pre class="message">On Thu, Sep 08, 2011 at 04:18:34PM -0700, Russ Allbery wrote: > (I don't recall if anyone tried to loop you into that discussion; if that > didn't happen, that was a flaw in that discussion process to be sure.) Nope, sorry, I missed that. -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="78"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 07:09:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=79">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=79">mbox</a>, <a href="#78">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="80"></a>   <strong>Acknowledgement sent</strong> to <code>Josip Rodin <joy@debbugs.entuzijast.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 07:09:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=81">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=81">mbox</a>, <a href="#80">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="82"></a><a name="msg82"></a><a href="#82">Message #82</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=82">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=82">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Fri%2C%209%20Sep%202011%2009%3A06%3A09%20%2B0200%20Josip%20Rodin%20%3Cjoy%40debbugs.entuzijast.net%3E%20wrote%3A%0A%3E%20%0A%3E%20Since%20my%20reasoning%20here%20didn%27t%20seem%20to%20leave%20a%20particular%20positive%20dent%20with%0A%3E%20those%20tech-ctte%20members%20who%20have%20responded%20so%20far%2C%20I%20would%20just%20like%20to%0A%3E%20solicit%20Ian%20Jackson%27s%20input%2C%20given%20his%20role%20in%20defining%20and%20implementing%20the%0A%3E%20debian%2Frules%20calling%20convention%20originally.%20In%20other%20worse%2C%20if%20I%20can%27t%0A%3E%20convince%20the%20original%20author%20of%20a%20non-make-dependent%20API%20that%20the%20API%20isn%27t%0A%3E%20make-dependent%2C%20there%20is%20no%20recourse%20but%20to%20yield%20%3A%29%0A%3E%20%0A%3E%20Or%20if%20my%20memory%20serves%20me%20wrong%20and%20it%20was%20instead%20some%20other%20person%2C%0A%3E%20particularly%20one%20that%20isn%27t%20intricately%20involved%20with%20Debian%20or%20can%27t%20be%0A%3E%20reached%20any%20more%2C%20I%27m%20also%20done.%0A%3E%20%0A%3E%20--%20%0A%3E%20%20%20%20%20%202.%20That%20which%20causes%20joy%20or%20happiness.%0A%3E%20%0A%3E%20%0A%3E%20%0A&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110909070608.GC19064%40entuzijast.net%3E&In-Reply-To=%3C20110909070608.GC19064%40entuzijast.net%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=joy%40debbugs.entuzijast.net" alt=""> <div class="header"><span class="headerfield">From:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Ian Jackson <ijackson@chiark.greenend.org.uk></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Fri, 9 Sep 2011 09:06:09 +0200</div> </div> <pre class="message"> Since my reasoning here didn't seem to leave a particular positive dent with those tech-ctte members who have responded so far, I would just like to solicit Ian Jackson's input, given his role in defining and implementing the debian/rules calling convention originally. In other worse, if I can't convince the original author of a non-make-dependent API that the API isn't make-dependent, there is no recourse but to yield :) Or if my memory serves me wrong and it was instead some other person, particularly one that isn't intricately involved with Debian or can't be reached any more, I'm also done. -- 2. That which causes joy or happiness. </pre> <div class="infmessage"><hr><p> <a name="83"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Fri, 09 Sep 2011 10:00:26 GMT) (<a href="bugreport.cgi?bug=640874;msg=84">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=84">mbox</a>, <a href="#83">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="85"></a>   <strong>Acknowledgement sent</strong> to <code>Steve Langasek <vorlon@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Fri, 09 Sep 2011 10:00:31 GMT) (<a href="bugreport.cgi?bug=640874;msg=86">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=86">mbox</a>, <a href="#85">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="87"></a><a name="msg87"></a><a href="#87">Message #87</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=87">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=87">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Fri%2C%209%20Sep%202011%2010%3A56%3A59%20%2B0100%20Steve%20Langasek%20%3Cvorlon%40debian.org%3E%20wrote%3A%0A%3E%20On%20Thu%2C%20Sep%2008%2C%202011%20at%2004%3A18%3A50PM%20%2B0200%2C%20Josip%20Rodin%20wrote%3A%0A%3E%20%3E%20Ahem%2C%20so%20I%20must%20quote%20it%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%23%21%2Fbin%2Fsh%20-e%0A%3E%20%3E%20%0A%3E%20%3E%20tmp%3D%60pwd%60%2Fdebian%2Fleave%0A%3E%20%3E%20%0A%3E%20%3E%20if%20echo%20%24DEB_BUILD_OPTIONS%20%7C%20grep%20-vq%20noopt%3B%20then%0A%3E%20%3E%20%20%20optflag%3D%22-O2%22%0A%3E%20%3E%20fi%0A%3E%20%0A%3E%20%3E%20if%20echo%20%24DEB_BUILD_OPTIONS%20%7C%20grep%20-vq%20nostrip%3B%20then%0A%3E%20%3E%20%20%20stripflag%3D%22-s%22%0A%3E%20%3E%20fi%0A%3E%20%0A%3E%20Does%20not%20do%20a%20word-wise%20search%20for%20the%20option%20names%2C%20preventing%20future%0A%3E%20compatibility%20with%20other%20options%20having%20these%20options%20as%20substrings.%20%0A%3E%20Whereas%20the%20naive%20implementation%20using%20make%20would%20DTRT.%20%20So%20that%27s%20strike%0A%3E%20one.%20%3B%29%0A%3E%20%0A%3E%20%3E%20%3E%20%3E%20The%20whole%20idea%20that%20we%27re%20changing%20something%20in%20the%20build-arch%20handling%0A%3E%20%3E%20%3E%20%3E%20is%20a%20nice%20supporting%20argument%20for%20my%20idea%20that%20we%20don%27t%20have%20a%20reason%20to%0A%3E%20%3E%20%3E%20%3E%20hardcode%20make%20-%20the%20fact%20that%20we%20control%20the%20API%20means%20that%20we%20are%20able%0A%3E%20%3E%20%3E%20%3E%20to%20make%20this%20decision%2C%20rather%20than%20having%20to%20adjust%20to%20whatever%20some%0A%3E%20%3E%20%3E%20%3E%20semi-random%20program%20does.%0A%3E%20%0A%3E%20%3E%20%3E%20If%20you%20ignore%20all%20transitions%20constraints%2C%20sure.%20At%20the%20same%20time%2C%20Debian%0A%3E%20%3E%20%3E%20decided%20debian%2Frules%20must%20be%20a%20Makefile%20and%20you%27re%20not%20adjusting%20to%20cope.%0A%3E%20%0A%3E%20%3E%20No%2C%20%22Debian%22%20did%20not%20decide%20to%20explicitly%20ban%20non-shell%20rules%20files%20at%20any%0A%3E%20%3E%20point%20in%20time%2C%20it%20was%20a%20leftover%20from%20a%20text%20conversion%20that%20never%20got%0A%3E%20%3E%20fixed.%0A%3E%20%0A%3E%20I%20disagree%20with%20this%20interpretation%20of%20the%20history%20of%20the%20requirement%0A%3E%20%28agreeing%20instead%20with%20Bdale%29%2C%20but%20if%20it%20would%20put%20this%20issue%20to%20rest%2C%20I%0A%3E%20would%20be%20happy%20to%20vote%20on%20it%20explicitly%20with%20the%20TC%20to%20require%20a%20makefile.%20%0A%3E%20The%20handful%20of%20exceptions%20have%20definitely%20caused%20us%20far%20more%20trouble%20as%20a%0A%3E%20project%20than%20any%20benefit%20you%20get%20as%20a%20maintainer%20from%20using%20a%20shell%20script%0A%3E%20in%20place%20of%20a%20makefile.%0A%3E%20%0A%3E%20--%20%0A%3E%20Steve%20Langasek%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Give%20me%20a%20lever%20long%20enough%20and%20a%20Free%20OS%0A%3E%20Debian%20Developer%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20to%20set%20it%20on%2C%20and%20I%20can%20move%20the%20world.%0A%3E%20Ubuntu%20Developer%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20http%3A%2F%2Fwww.debian.org%2F%0A%3E%20slangasek%40ubuntu.com%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20vorlon%40debian.org%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&In-Reply-To=%3C20110909095659.GB25551%40virgil.dodds.net%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C20110908075940.GA2168%40entuzijast.net%3E%0A%20%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%20%3C20110908123815.GA13055%40entuzijast.net%3E%0A%20%3C20110908133839.GI23590%40rivendell.home.ouaza.com%3E%0A%20%3C20110908141850.GA7445%40entuzijast.net%3E%0A%20%3C20110909095659.GB25551%40virgil.dodds.net%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=vorlon%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Steve Langasek <vorlon@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Josip Rodin <joy@debbugs.entuzijast.net>, Raphael Hertzog <hertzog@debian.org></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Fri, 9 Sep 2011 10:56:59 +0100</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=87">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">On Thu, Sep 08, 2011 at 04:18:50PM +0200, Josip Rodin wrote: > Ahem, so I must quote it: > > #!/bin/sh -e > > tmp=`pwd`/debian/leave > > if echo $DEB_BUILD_OPTIONS | grep -vq noopt; then > optflag="-O2" > fi > if echo $DEB_BUILD_OPTIONS | grep -vq nostrip; then > stripflag="-s" > fi Does not do a word-wise search for the option names, preventing future compatibility with other options having these options as substrings. Whereas the naive implementation using make would DTRT. So that's strike one. ;) > > > The whole idea that we're changing something in the build-arch handling > > > is a nice supporting argument for my idea that we don't have a reason to > > > hardcode make - the fact that we control the API means that we are able > > > to make this decision, rather than having to adjust to whatever some > > > semi-random program does. > > If you ignore all transitions constraints, sure. At the same time, Debian > > decided debian/rules must be a Makefile and you're not adjusting to cope. > No, "Debian" did not decide to explicitly ban non-shell rules files at any > point in time, it was a leftover from a text conversion that never got > fixed. I disagree with this interpretation of the history of the requirement (agreeing instead with Bdale), but if it would put this issue to rest, I would be happy to vote on it explicitly with the TC to require a makefile. The handful of exceptions have definitely caused us far more trouble as a project than any benefit you get as a maintainer from using a shell script in place of a makefile. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer <a href="http://www.debian.org/">http://www.debian.org/</a> slangasek@ubuntu.com vorlon@debian.org </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;filename=signature.asc;msg=87">signature.asc</a> (application/pgp-signature, inline)]</pre> <div class="infmessage"><hr><p> <a name="88"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Tue, 13 Sep 2011 09:39:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=89">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=89">mbox</a>, <a href="#88">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="90"></a>   <strong>Acknowledgement sent</strong> to <code>Ian Jackson <ijackson@chiark.greenend.org.uk></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Tue, 13 Sep 2011 09:39:15 GMT) (<a href="bugreport.cgi?bug=640874;msg=91">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=91">mbox</a>, <a href="#90">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="92"></a><a name="msg92"></a><a href="#92">Message #92</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=92">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=92">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Tue%2C%2013%20Sep%202011%2010%3A37%3A38%20%2B0100%20Ian%20Jackson%20%3Cijackson%40chiark.greenend.org.uk%3E%20wrote%3A%0A%3E%20Josip%20Rodin%20writes%20%28%22Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile%22%29%3A%0A%3E%20%3E%20Since%20my%20reasoning%20here%20didn%27t%20seem%20to%20leave%20a%20particular%20positive%20dent%20with%0A%3E%20%3E%20those%20tech-ctte%20members%20who%20have%20responded%20so%20far%2C%20I%20would%20just%20like%20to%0A%3E%20%3E%20solicit%20Ian%20Jackson%27s%20input%2C%20given%20his%20role%20in%20defining%20and%20implementing%20the%0A%3E%20%3E%20debian%2Frules%20calling%20convention%20originally.%20In%20other%20worse%2C%20if%20I%20can%27t%0A%3E%20%3E%20convince%20the%20original%20author%20of%20a%20non-make-dependent%20API%20that%20the%20API%20isn%27t%0A%3E%20%3E%20make-dependent%2C%20there%20is%20no%20recourse%20but%20to%20yield%20%3A%29%0A%3E%20%0A%3E%20It%27s%20very%20tempting%20to%20close%20down%20this%20discussion%20by%20agreeing%20that%20we%0A%3E%20always%20intended%20debian%2Frules%20to%20only%20be%20allowed%20to%20be%20a%20makefile.%20%20But%0A%3E%20I%27m%20afraid%20that%20I%27m%20going%20to%20agree%20with%20Josip%20on%20this%20point%3A%20as%20far%20as%0A%3E%20I%20remember%2C%20the%20designers%20%28of%20which%20I%20was%20one%29%20did%20not%20originally%0A%3E%20intend%20this%20restriction.%20%20If%20I%20had%20intended%20it%20I%20would%20have%20written%20it%0A%3E%20into%20the%20original%20policy%20manual.%0A%3E%20%0A%3E%20That%20doesn%27t%20mean%20that%20in%20the%20current%20circumstances%20it%20isn%27t%0A%3E%20reasonable%20to%20make%20that%20requirement%2C%20of%20course.%20%20But%20I%27m%20not%20convinced%0A%3E%20by%20the%20arguments%20made%20so%20far%20in%20favour%20of%20this%20requirement.%0A%3E%20%0A%3E%20It%27s%20true%20that%20having%20a%20standardised%20implementation%20language%20can%0A%3E%20make%20it%20easier%20for%20people%20unfamiliar%20with%20the%20package%20to%20work%20with%20it%2C%0A%3E%20and%20this%20is%20indeed%20something%20that%20we%20should%20care%20about.%0A%3E%20%0A%3E%20But%20I%20agree%20with%20Josip%27s%20point%20about%20the%20spirit%20vs.%20the%20letter%3A%20if%20we%0A%3E%20write%20into%20policy%20that%20debian%2Frules%20must%20be%20a%20makefile%2C%20Josip%20can%0A%3E%20comply%20with%20the%20policy%20by%20what%20amounts%20IMO%20to%20trickery.%20%20And%20it%27s%20not%0A%3E%20trickery%20that%27s%20simple%20to%20forbid%2C%20given%20that%20that%20trickery%20is%20exactly%0A%3E%20what%20dh%281%29%20uses.%0A%3E%20%0A%3E%20Or%20to%20put%20it%20another%20way%2C%20we%20have%20two%20plausible%20options%3A%0A%3E%20%0A%3E%20%201.%20Weaken%20the%20rule%20that%20debian%2Frules%20must%20be%20a%20makefile%2C%20from%20a%0A%3E%20%20%20%20%20requirement%20to%20a%20recommendation.%0A%3E%20%0A%3E%20%202.%20Require%20that%20it%20be%20a%20makefile%20but%20permit%0A%3E%20%09%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%09%25%3A%0A%3E%20%09%09debian%2Fmyscript%20%24%40%0A%3E%20%20%20%20%20and%20also%3A%0A%3E%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%09%09dh%20%24%40%0A%3E%20%0A%3E%20And%20one%20implausible%20one%3A%0A%3E%20%0A%3E%20%203.%20Require%20that%20it%20be%20a%20makefile%20and%20FORBID%0A%3E%20%09%25%3A%0A%3E%20%09%09debian%2Fmyscript%20%24%40%0A%3E%20%20%20%20%20but%20PERMIT%0A%3E%20%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%09%09dh%20%24%40%0A%3E%20%0A%3E%20Of%20these%20I%20prefer%20option%201.%20%20It%20is%20at%20least%20coherent.%20%20An%20imprecation%0A%3E%20in%20policy%20%2Frecommending%2F%20the%20use%20of%20make%20or%20dh%281%29%20would%20be%20sensible.%0A%3E%20%0A%3E%20Option%202%20is%20pointless%20IMO.%20%20It%20mandates%20that%20Josip%20do%20something%0A%3E%20pointless%2C%20and%20leaves%20the%20same%20door%20open%20for%20other%20pointless%20things.%0A%3E%20%0A%3E%20Option%203%20is%20very%20difficult%3A%20how%20do%20we%20distinguish%20these%20two%20cases%20%3F%0A%3E%20Are%20we%20going%20to%20make%20a%20special%20exception%20for%20dh%281%29%2C%20thus%20forbidding%0A%3E%20future%20package%20helper%20tools%20that%20aren%27t%20explicitly%20blessed%20by%20policy%20%3F%0A&In-Reply-To=%3C20079.9314.758215.667015%40chiark.greenend.org.uk%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C20110908075940.GA2168%40entuzijast.net%3E%0A%09%3C20110908094343.GA22574%40riva.dynamic.greenend.org.uk%3E%0A%09%3C20110909070608.GC19064%40entuzijast.net%3E%0A%20%3C20079.9314.758215.667015%40chiark.greenend.org.uk%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=ijackson%40chiark.greenend.org.uk" alt=""> <div class="header"><span class="headerfield">From:</span> Ian Jackson <ijackson@chiark.greenend.org.uk></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Tue, 13 Sep 2011 10:37:38 +0100</div> </div> <pre class="message">Josip Rodin writes ("Bug#640874: leave: debian/rules is not a Makefile"): > Since my reasoning here didn't seem to leave a particular positive dent with > those tech-ctte members who have responded so far, I would just like to > solicit Ian Jackson's input, given his role in defining and implementing the > debian/rules calling convention originally. In other worse, if I can't > convince the original author of a non-make-dependent API that the API isn't > make-dependent, there is no recourse but to yield :) It's very tempting to close down this discussion by agreeing that we always intended debian/rules to only be allowed to be a makefile. But I'm afraid that I'm going to agree with Josip on this point: as far as I remember, the designers (of which I was one) did not originally intend this restriction. If I had intended it I would have written it into the original policy manual. That doesn't mean that in the current circumstances it isn't reasonable to make that requirement, of course. But I'm not convinced by the arguments made so far in favour of this requirement. It's true that having a standardised implementation language can make it easier for people unfamiliar with the package to work with it, and this is indeed something that we should care about. But I agree with Josip's point about the spirit vs. the letter: if we write into policy that debian/rules must be a makefile, Josip can comply with the policy by what amounts IMO to trickery. And it's not trickery that's simple to forbid, given that that trickery is exactly what dh(1) uses. Or to put it another way, we have two plausible options: 1. Weaken the rule that debian/rules must be a makefile, from a requirement to a recommendation. 2. Require that it be a makefile but permit #!/usr/bin/make -f %: debian/myscript $@ and also: %: dh $@ And one implausible one: 3. Require that it be a makefile and FORBID %: debian/myscript $@ but PERMIT %: dh $@ Of these I prefer option 1. It is at least coherent. An imprecation in policy /recommending/ the use of make or dh(1) would be sensible. Option 2 is pointless IMO. It mandates that Josip do something pointless, and leaves the same door open for other pointless things. Option 3 is very difficult: how do we distinguish these two cases ? Are we going to make a special exception for dh(1), thus forbidding future package helper tools that aren't explicitly blessed by policy ? I don't think that's the right way to go. Ian. </pre> <div class="infmessage"><hr><p> <a name="93"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Sat, 10 Dec 2011 01:51:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=94">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=94">mbox</a>, <a href="#93">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="95"></a>   <strong>Acknowledgement sent</strong> to <code>peter green <plugwash@p10link.net></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Sat, 10 Dec 2011 01:51:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=96">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=96">mbox</a>, <a href="#95">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="97"></a><a name="msg97"></a><a href="#97">Message #97</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=97">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=97">mbox</a>, <a href="mailto:640874@bugs.debian.org?In-Reply-To=%3C4EE2BAB8.5040703%40p10link.net%3E&References=%3C4EE2BAB8.5040703%40p10link.net%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Sat%2C%2010%20Dec%202011%2001%3A49%3A44%20%2B0000%20peter%20green%20%3Cplugwash%40p10link.net%3E%20wrote%3A%0A%3E%20Ian%20Jackson%20wrote%3A%0A%3E%20%3EBut%20I%20agree%20with%20Josip%27s%20point%20about%20the%20spirit%20vs.%20the%20letter%3A%20if%20we%0A%3E%20%3Ewrite%20into%20policy%20that%20debian%2Frules%20must%20be%20a%20makefile%2C%20Josip%20can%0A%3E%20%3Ecomply%20with%20the%20policy%20by%20what%20amounts%20IMO%20to%20trickery.%20%20And%20it%27s%20not%0A%3E%20%3Etrickery%20that%27s%20simple%20to%20forbid%2C%20given%20that%20that%20trickery%20is%20exactly%0A%3E%20%3Ewhat%20dh%281%29%20uses.%0A%3E%20----SNIP-----%0A%3E%20%3EAnd%20one%20implausible%20one%3A%0A%3E%20%3E%0A%3E%20%3E%203.%20Require%20that%20it%20be%20a%20makefile%20and%20FORBID%0A%3E%20%3E%09%25%3A%0A%3E%20%3E%09%09debian%2Fmyscript%20%24%40%0A%3E%20%3E%20%20%20%20but%20PERMIT%0A%3E%20%3E%20%20%20%20%20%20%20%20%25%3A%0A%3E%20%3E%09%09dh%20%24%40%0A%3E%20%0A%3E%20%0A%3E%20Just%20an%20idea%20as%20an%20outsider%20how%20about%0A%3E%20%0A%3E%204%3A%20Require%20it%20be%20a%20makefile%20and%20additionally%20require%20that%20if%20the%20makefile%20%0A%3E%20%20%20%20makes%20use%20of%20wildcards%20it%20must%20implement%20a%20%22listtargets%22%20target.%0A%3E%20%0A%3E%20%20%20%20Listtargets%20would%20return%20a%20list%20of%20supported%20targets.%20Tools%20looking%0A%3E%20%20%20%20for%20targets%20would%20search%20the%20makefile%20for%20targets%20and%20run%20%0A%3E%20%20%20%20debian%2Flisttargets%20if%20they%20found%20wildcards.%0A%3E%20%0A%3E%20That%20way%20tools%20could%20still%20get%20a%20list%20of%20supported%20targets%20even%20if%0A%3E%20wildcards%20are%20used%20and%20dh%20wouldn%27t%20need%20to%20be%20special%20cased%20%28though%20it%0A%3E%20would%20need%20to%20be%20modified%20to%20implement%20the%20new%20target%29.%0A%3E%20%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=plugwash%40p10link.net" alt=""> <div class="header"><span class="headerfield">From:</span> peter green <plugwash@p10link.net></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Sat, 10 Dec 2011 01:49:44 +0000</div> </div> <pre class="message flowed">Ian Jackson wrote: >But I agree with Josip's point about the spirit vs. the letter: if we >write into policy that debian/rules must be a makefile, Josip can >comply with the policy by what amounts IMO to trickery. And it's not >trickery that's simple to forbid, given that that trickery is exactly >what dh(1) uses. ----SNIP----- >And one implausible one: > > 3. Require that it be a makefile and FORBID > %: > debian/myscript $@ > but PERMIT > %: > dh $@ Just an idea as an outsider how about 4: Require it be a makefile and additionally require that if the makefile makes use of wildcards it must implement a "listtargets" target. Listtargets would return a list of supported targets. Tools looking for targets would search the makefile for targets and run debian/listtargets if they found wildcards. That way tools could still get a list of supported targets even if wildcards are used and dh wouldn't need to be special cased (though it would need to be modified to implement the new target). </pre> <div class="infmessage"><hr><p> <a name="98"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Mon, 19 Mar 2012 04:33:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=99">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=99">mbox</a>, <a href="#98">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="100"></a>   <strong>Acknowledgement sent</strong> to <code>Russ Allbery <rra@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Mon, 19 Mar 2012 04:33:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=101">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=101">mbox</a>, <a href="#100">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="102"></a><a name="msg102"></a><a href="#102">Message #102</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=102">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=102">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E&In-Reply-To=%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Sun%2C%2018%20Mar%202012%2021%3A30%3A47%20-0700%20Russ%20Allbery%20%3Crra%40debian.org%3E%20wrote%3A%0A%3E%20My%20impression%20is%20that%20discussion%20on%20this%20bug%20has%20wound%20down%2C%20and%20that%20it%27s%0A%3E%20unlikely%20that%20any%20new%20information%20is%20going%20to%20come%20up.%20%20To%20me%2C%20that%0A%3E%20implies%20that%20we%20should%20call%20for%20a%20vote.%0A%3E%20%0A%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20dh%3A%0A%3E%20%0A%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%0A%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20Are%20there%20any%20corrections%20or%20modifications%20to%20that%20ballot%3F%20%20Anything%20I%27m%0A%3E%20missing%3F%0A%3E%20%0A%3E%20If%20there%20are%20no%20objections%2C%20I%27ll%20call%20for%20a%20vote%20on%20this%20ballot%20in%20a%20few%0A%3E%20days.%0A%3E%20%0A%3E%20--%20%0A%3E%20Russ%20Allbery%20%28rra%40debian.org%29%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Chttp%3A%2F%2Fwww.eyrie.org%2F~eagle%2F%3E%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=rra%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">To:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Cc:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Sun, 18 Mar 2012 21:30:47 -0700</div> </div> <pre class="message">My impression is that discussion on this bug has wound down, and that it's unlikely that any new information is going to come up. To me, that implies that we should call for a vote. Based on Ian's last response, I think the ballot has two options plus further discussion, since I'm quite sure that we're not going to outlaw dh: A. debian/rules is not required to be a makefile, only to implement the same interface as a debian/rules file implemented as a makefile (including handling of arguments and exit status). Debian Policy should be updated to change the requirement to a recommendation, and new versions of the leave package should be permitted to be uploaded to the archive without changing debian/rules to be a makefile. B. The Technical Committee affirms the Debian Policy requirement that debian/rules must be a makefile. All packages in the archive, including leave, are required to follow this requirement. This makefile may, as is common practice, delegate implementation of its targets to a script. C. Further discussion. Are there any corrections or modifications to that ballot? Anything I'm missing? If there are no objections, I'll call for a vote on this ballot in a few days. -- Russ Allbery (rra@debian.org) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>> </pre> <div class="infmessage"><hr><p> <a name="103"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Wed, 21 Mar 2012 18:51:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=104">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=104">mbox</a>, <a href="#103">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="105"></a>   <strong>Acknowledgement sent</strong> to <code>Russ Allbery <rra@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Wed, 21 Mar 2012 18:51:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=106">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=106">mbox</a>, <a href="#105">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="107"></a><a name="msg107"></a><a href="#107">Message #107</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=107">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=107">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Wed%2C%2021%20Mar%202012%2011%3A46%3A47%20-0700%20Russ%20Allbery%20%3Crra%40debian.org%3E%20wrote%3A%0A%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20dh%3A%0A%3E%20%0A%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%0A%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20Hearing%20no%20objections%2C%20I%20call%20for%20a%20vote%20on%20this%20ballot.%0A%3E%20%0A%3E%20--%20%0A%3E%20Russ%20Allbery%20%28rra%40debian.org%29%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Chttp%3A%2F%2Fwww.eyrie.org%2F~eagle%2F%3E%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%20%3C87limt94h4.fsf%40windlord.stanford.edu%3E&In-Reply-To=%3C87limt94h4.fsf%40windlord.stanford.edu%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=rra%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Wed, 21 Mar 2012 11:46:47 -0700</div> </div> <pre class="message">Russ Allbery <rra@debian.org> writes: > Based on Ian's last response, I think the ballot has two options plus > further discussion, since I'm quite sure that we're not going to outlaw > dh: > A. debian/rules is not required to be a makefile, only to implement the > same interface as a debian/rules file implemented as a makefile > (including handling of arguments and exit status). Debian Policy > should be updated to change the requirement to a recommendation, and > new versions of the leave package should be permitted to be uploaded to > the archive without changing debian/rules to be a makefile. > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. > C. Further discussion. Hearing no objections, I call for a vote on this ballot. -- Russ Allbery (rra@debian.org) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>> </pre> <div class="infmessage"><hr><p> <a name="108"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Wed, 21 Mar 2012 19:33:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=109">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=109">mbox</a>, <a href="#108">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="110"></a>   <strong>Acknowledgement sent</strong> to <code>Russ Allbery <rra@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Wed, 21 Mar 2012 19:33:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=111">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=111">mbox</a>, <a href="#110">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="112"></a><a name="msg112"></a><a href="#112">Message #112</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=112">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=112">mbox</a>, <a href="mailto:640874@bugs.debian.org?In-Reply-To=%3C877gyd92hs.fsf%40windlord.stanford.edu%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%09%3C87limt94h4.fsf%40windlord.stanford.edu%3E%0A%20%3C877gyd92hs.fsf%40windlord.stanford.edu%3E&body=On%20Wed%2C%2021%20Mar%202012%2012%3A29%3A35%20-0700%20Russ%20Allbery%20%3Crra%40debian.org%3E%20wrote%3A%0A%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%3E%20dh%3A%0A%3E%20%0A%3E%20%3E%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%0A%3E%20%3E%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20%3E%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20%3E%20Hearing%20no%20objections%2C%20I%20call%20for%20a%20vote%20on%20this%20ballot.%0A%3E%20%0A%3E%20I%20vote%20BAC.%0A%3E%20%0A%3E%20--%20%0A%3E%20Russ%20Allbery%20%28rra%40debian.org%29%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Chttp%3A%2F%2Fwww.eyrie.org%2F~eagle%2F%3E%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=rra%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Wed, 21 Mar 2012 12:29:35 -0700</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=112">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">Russ Allbery <rra@debian.org> writes: > Russ Allbery <rra@debian.org> writes: >> Based on Ian's last response, I think the ballot has two options plus >> further discussion, since I'm quite sure that we're not going to outlaw >> dh: >> A. debian/rules is not required to be a makefile, only to implement the >> same interface as a debian/rules file implemented as a makefile >> (including handling of arguments and exit status). Debian Policy >> should be updated to change the requirement to a recommendation, and >> new versions of the leave package should be permitted to be uploaded to >> the archive without changing debian/rules to be a makefile. >> B. The Technical Committee affirms the Debian Policy requirement that >> debian/rules must be a makefile. All packages in the archive, >> including leave, are required to follow this requirement. This >> makefile may, as is common practice, delegate implementation of its >> targets to a script. >> C. Further discussion. > Hearing no objections, I call for a vote on this ballot. I vote BAC. -- Russ Allbery (rra@debian.org) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>> </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;msg=112">Message part 2</a> (application/pgp-signature, inline)]</pre> <div class="infmessage"><hr><p> <a name="113"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Wed, 21 Mar 2012 22:51:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=114">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=114">mbox</a>, <a href="#113">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="115"></a>   <strong>Acknowledgement sent</strong> to <code>Ian Jackson <ijackson@chiark.greenend.org.uk></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Wed, 21 Mar 2012 22:51:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=116">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=116">mbox</a>, <a href="#115">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="117"></a><a name="msg117"></a><a href="#117">Message #117</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=117">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=117">mbox</a>, <a href="mailto:640874@bugs.debian.org?In-Reply-To=%3C20330.23138.412354.985279%40chiark.greenend.org.uk%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%09%3C87limt94h4.fsf%40windlord.stanford.edu%3E%0A%20%3C20330.23138.412354.985279%40chiark.greenend.org.uk%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Wed%2C%2021%20Mar%202012%2022%3A46%3A58%20%2B0000%20Ian%20Jackson%20%3Cijackson%40chiark.greenend.org.uk%3E%20wrote%3A%0A%3E%20Russ%20Allbery%20writes%20%28%22Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile%22%29%3A%0A%3E%20%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20%3E%20dh%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20I%20vote%20AB.%0A%3E%20%0A%3E%20Ian.%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=ijackson%40chiark.greenend.org.uk" alt=""> <div class="header"><span class="headerfield">From:</span> Ian Jackson <ijackson@chiark.greenend.org.uk></div> <div class="header"><span class="headerfield">To:</span> Russ Allbery <rra@debian.org>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Wed, 21 Mar 2012 22:46:58 +0000</div> </div> <pre class="message">Russ Allbery writes ("Bug#640874: leave: debian/rules is not a Makefile"): > Russ Allbery <rra@debian.org> writes: > > Based on Ian's last response, I think the ballot has two options plus > > further discussion, since I'm quite sure that we're not going to outlaw > > dh: > > > A. debian/rules is not required to be a makefile, only to implement the > > same interface as a debian/rules file implemented as a makefile > > (including handling of arguments and exit status). Debian Policy > > should be updated to change the requirement to a recommendation, and > > new versions of the leave package should be permitted to be uploaded to > > the archive without changing debian/rules to be a makefile. > > > B. The Technical Committee affirms the Debian Policy requirement that > > debian/rules must be a makefile. All packages in the archive, > > including leave, are required to follow this requirement. This > > makefile may, as is common practice, delegate implementation of its > > targets to a script. I vote AB. Ian. </pre> <div class="infmessage"><hr><p> <a name="118"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Wed, 21 Mar 2012 23:00:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=119">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=119">mbox</a>, <a href="#118">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="120"></a>   <strong>Acknowledgement sent</strong> to <code>Ian Jackson <ijackson@chiark.greenend.org.uk></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Wed, 21 Mar 2012 23:00:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=121">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=121">mbox</a>, <a href="#120">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="122"></a><a name="msg122"></a><a href="#122">Message #122</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=122">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=122">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%09%3C87limt94h4.fsf%40windlord.stanford.edu%3E%0A%09%3C877gyd92hs.fsf%40windlord.stanford.edu%3E%0A%20%3C20330.23788.518361.934829%40chiark.greenend.org.uk%3E&In-Reply-To=%3C20330.23788.518361.934829%40chiark.greenend.org.uk%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Wed%2C%2021%20Mar%202012%2022%3A57%3A48%20%2B0000%20Ian%20Jackson%20%3Cijackson%40chiark.greenend.org.uk%3E%20wrote%3A%0A%3E%20Russ%20Allbery%20writes%20%28%22Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile%22%29%3A%0A%3E%20%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%3E%20%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%3E%20%3E%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%3E%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%3E%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%3E%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%3E%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20Just%20to%20be%20clear%2C%20my%20interpretation%20of%20option%20B%20is%20that%20the%20leave%0A%3E%20maintainer%20is%20at%20liberty%20to%20do%20this%3A%0A%3E%20%0A%3E%20%20%20%20%24%20mv%20debian%2Frules%20debian%2Frules.mine%0A%3E%20%20%20%20%24%20cat%20%3Edebian%2Frules%0A%3E%20%20%20%20%23%21%2Fusr%2Fbin%2Fmake%20-f%0A%3E%20%20%20%20%25%3A%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20chmmod%20%2Bx%20debian%2Frules.mine%0A%3E%20%20%20%20%20%20%20%20%20%20%20%20debian%2Frules.mine%20%24%40%0A%3E%20%20%20%20%5ED%0A%3E%20%20%20%20%24%20chmod%20%2Bx%20debian%2Frules%0A%3E%20%0A%3E%20But%20they%20are%20not%20entitled%20to%20do%20nothing.%20%20I%20think%20this%20is%20entirely%0A%3E%20daft.%20%20Hence%20my%20vote%20for%20optionn%20A.%0A%3E%20%0A%3E%20Ian.%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=ijackson%40chiark.greenend.org.uk" alt=""> <div class="header"><span class="headerfield">From:</span> Ian Jackson <ijackson@chiark.greenend.org.uk></div> <div class="header"><span class="headerfield">To:</span> Russ Allbery <rra@debian.org>, 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Wed, 21 Mar 2012 22:57:48 +0000</div> </div> <pre class="message">Russ Allbery writes ("Bug#640874: leave: debian/rules is not a Makefile"): > Russ Allbery <rra@debian.org> writes: > > Russ Allbery <rra@debian.org> writes: > >> B. The Technical Committee affirms the Debian Policy requirement that > >> debian/rules must be a makefile. All packages in the archive, > >> including leave, are required to follow this requirement. This > >> makefile may, as is common practice, delegate implementation of its > >> targets to a script. Just to be clear, my interpretation of option B is that the leave maintainer is at liberty to do this: $ mv debian/rules debian/rules.mine $ cat >debian/rules #!/usr/bin/make -f %: chmmod +x debian/rules.mine debian/rules.mine $@ ^D $ chmod +x debian/rules But they are not entitled to do nothing. I think this is entirely daft. Hence my vote for optionn A. Ian. </pre> <div class="infmessage"><hr><p> <a name="123"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Mon, 26 Mar 2012 19:15:04 GMT) (<a href="bugreport.cgi?bug=640874;msg=124">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=124">mbox</a>, <a href="#123">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="125"></a>   <strong>Acknowledgement sent</strong> to <code>Don Armstrong <don@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Mon, 26 Mar 2012 19:15:04 GMT) (<a href="bugreport.cgi?bug=640874;msg=126">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=126">mbox</a>, <a href="#125">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="127"></a><a name="msg127"></a><a href="#127">Message #127</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=127">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=127">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%20%3C20120326191151.GH16976%40rzlab.ucr.edu%3E&In-Reply-To=%3C20120326191151.GH16976%40rzlab.ucr.edu%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Mon%2C%2026%20Mar%202012%2012%3A11%3A51%20-0700%20Don%20Armstrong%20%3Cdon%40debian.org%3E%20wrote%3A%0A%3E%20On%20Sun%2C%2018%20Mar%202012%2C%20Russ%20Allbery%20wrote%3A%0A%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20dh%3A%0A%3E%20%3E%20%0A%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%3E%20%0A%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%3E%20%0A%3E%20%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20I%20vote%20BAC.%0A%3E%20%20%0A%3E%20%0A%3E%20Don%20Armstrong%0A%3E%20%0A%3E%20--%20%0A%3E%20More%20than%20any%20other%20time%20in%20history%2C%20mankind%20faces%20a%20crossroads.%0A%3E%20One%20path%20leads%20to%20despair%20and%20utter%20hopelessness.%0A%3E%20The%20other%2C%20to%20total%20extinction.%0A%3E%20Let%20us%20pray%20we%20have%20the%20wisdom%20to%20choose%20correctly.%0A%3E%20%20--%20Woody%20Allen%0A%3E%20%0A%3E%20http%3A%2F%2Fwww.donarmstrong.com%20%20%20%20%20%20%20%20%20%20%20%20%20%20http%3A%2F%2Frzlab.ucr.edu%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=don%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Don Armstrong <don@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Mon, 26 Mar 2012 12:11:51 -0700</div> </div> <pre class="message">On Sun, 18 Mar 2012, Russ Allbery wrote: > Based on Ian's last response, I think the ballot has two options plus > further discussion, since I'm quite sure that we're not going to outlaw > dh: > > A. debian/rules is not required to be a makefile, only to implement the > same interface as a debian/rules file implemented as a makefile > (including handling of arguments and exit status). Debian Policy > should be updated to change the requirement to a recommendation, and > new versions of the leave package should be permitted to be uploaded to > the archive without changing debian/rules to be a makefile. > > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. > > C. Further discussion. I vote BAC. Don Armstrong -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen <a href="http://www.donarmstrong.com">http://www.donarmstrong.com</a> <a href="http://rzlab.ucr.edu">http://rzlab.ucr.edu</a> </pre> <div class="infmessage"><hr><p> <a name="128"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Mon, 26 Mar 2012 19:51:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=129">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=129">mbox</a>, <a href="#128">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="130"></a>   <strong>Acknowledgement sent</strong> to <code>Andreas Barth <aba@ayous.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Mon, 26 Mar 2012 19:51:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=131">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=131">mbox</a>, <a href="#130">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="132"></a><a name="msg132"></a><a href="#132">Message #132</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=132">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=132">mbox</a>, <a href="mailto:640874@bugs.debian.org?In-Reply-To=%3C20120326192133.GM2385%40mails.so.argh.org%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%20%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%20%3C87wr678a1j.fsf%40windlord.stanford.edu%3E%0A%20%3C20120326192133.GM2385%40mails.so.argh.org%3E&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Mon%2C%2026%20Mar%202012%2021%3A21%3A33%20%2B0200%20Andreas%20Barth%20%3Caba%40ayous.org%3E%20wrote%3A%0A%3E%20%2A%20Russ%20Allbery%20%28rra%40debian.org%29%20%5B120326%2020%3A58%5D%3A%0A%3E%20%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20%3E%20dh%3A%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%3E%20%0A%3E%20%3E%20%3E%20C.%20Further%20discussion.%0A%3E%20%3E%20%0A%3E%20%3E%20Reminder%3A%20there%20is%20a%20vote%20currently%20in%20progress%20on%20this%20ballot.%20%20So%20far%2C%0A%3E%20%3E%20only%20Ian%20and%20I%20have%20voted.%20%20Please%20take%20a%20look%20at%20the%20cited%20bug%20and%0A%3E%20%3E%20register%20an%20opinion%20when%20you%20have%20a%20chance.%0A%3E%20%0A%3E%20Thanks%20for%20the%20reminder.%0A%3E%20%0A%3E%20Voting%20BAC.%0A%3E%20%0A%3E%20%28I%27m%20not%20convinced%20that%20we%20gain%20anything%20by%20changing%20the%20status%20quo%20to%0A%3E%20the%20proposed%20solution%20A%20-%20even%20though%20with%20the%20current%20makefiles%0A%3E%20consisting%20of%20just%20%22%25%3A%20dh%20%24%40%22%20the%20degault%20mechanismn%20seems%20a%20bit%20too%0A%3E%20complicated%3B%20but%20changing%20that%20to%20variant%20A%20doesn%27t%20seem%20to%20be%20too%0A%3E%20useful.%20Also%2C%20the%20tech%20ctte%20isn%27t%20the%20place%20to%20develop%20new%20solutions%3B%0A%3E%20in%20other%20words%2C%20if%20someone%20comes%20up%20with%20a%20good%20solution%20which%20has%0A%3E%20shown%20through%20the%20usual%20ways%20that%20it%20gains%20something%20for%20debian%20at%0A%3E%20large%2C%20I%27m%20happy%20to%20support%20changing%20the%20default%20but%20we%27re%20not%20there%0A%3E%20%28yet%29.%29%0A%3E%20%0A%3E%20%0A%3E%20Andi%0A%3E%20%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=aba%40ayous.org" alt=""> <div class="header"><span class="headerfield">From:</span> Andreas Barth <aba@ayous.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Mon, 26 Mar 2012 21:21:33 +0200</div> </div> <pre class="message">* Russ Allbery (rra@debian.org) [120326 20:58]: > Russ Allbery <rra@debian.org> writes: > > > Based on Ian's last response, I think the ballot has two options plus > > further discussion, since I'm quite sure that we're not going to outlaw > > dh: > > > A. debian/rules is not required to be a makefile, only to implement the > > same interface as a debian/rules file implemented as a makefile > > (including handling of arguments and exit status). Debian Policy > > should be updated to change the requirement to a recommendation, and > > new versions of the leave package should be permitted to be uploaded to > > the archive without changing debian/rules to be a makefile. > > > B. The Technical Committee affirms the Debian Policy requirement that > > debian/rules must be a makefile. All packages in the archive, > > including leave, are required to follow this requirement. This > > makefile may, as is common practice, delegate implementation of its > > targets to a script. > > > C. Further discussion. > > Reminder: there is a vote currently in progress on this ballot. So far, > only Ian and I have voted. Please take a look at the cited bug and > register an opinion when you have a chance. Thanks for the reminder. Voting BAC. (I'm not convinced that we gain anything by changing the status quo to the proposed solution A - even though with the current makefiles consisting of just "%: dh $@" the degault mechanismn seems a bit too complicated; but changing that to variant A doesn't seem to be too useful. Also, the tech ctte isn't the place to develop new solutions; in other words, if someone comes up with a good solution which has shown through the usual ways that it gains something for debian at large, I'm happy to support changing the default but we're not there (yet).) Andi </pre> <div class="infmessage"><hr><p> <a name="133"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Sat, 31 Mar 2012 17:15:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=134">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=134">mbox</a>, <a href="#133">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="135"></a>   <strong>Acknowledgement sent</strong> to <code>Colin Watson <cjwatson@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Sat, 31 Mar 2012 17:15:06 GMT) (<a href="bugreport.cgi?bug=640874;msg=136">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=136">mbox</a>, <a href="#135">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="137"></a><a name="msg137"></a><a href="#137">Message #137</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=137">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=137">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Sat%2C%2031%20Mar%202012%2018%3A11%3A53%20%2B0100%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20wrote%3A%0A%3E%20On%20Sun%2C%20Mar%2018%2C%202012%20at%2009%3A30%3A47PM%20-0700%2C%20Russ%20Allbery%20wrote%3A%0A%3E%20%3E%20My%20impression%20is%20that%20discussion%20on%20this%20bug%20has%20wound%20down%2C%20and%20that%20it%27s%0A%3E%20%3E%20unlikely%20that%20any%20new%20information%20is%20going%20to%20come%20up.%20%20To%20me%2C%20that%0A%3E%20%3E%20implies%20that%20we%20should%20call%20for%20a%20vote.%0A%3E%20%0A%3E%20I%27m%20pretty%20sure%20I%27m%20unconstitutionally%20late%20for%20this%2C%20sorry%20%28I%27ve%20had%20a%0A%3E%20busy%20week%20and%20have%20not%20been%20checking%20Debian%20mail%20much%29.%20%20But%20just%20in%0A%3E%20case%20it%20matters%3A%0A%3E%20%0A%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20dh%3A%0A%3E%20%3E%20%0A%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%3E%20%0A%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%3E%20%0A%3E%20%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20I%20vote%20BAC.%0A%3E%20%0A%3E%20%0A%3E%20While%20I%20understand%20the%20position%20that%20B%20can%20lead%20to%20pathological%20results%2C%0A%3E%20in%20practice%20I%27m%20not%20aware%20of%20this%20happening%20in%20practice%2C%20or%20if%20it%20is%0A%3E%20then%20it%27s%20a%20trivial%20number%20of%20cases%3B%20developers%20generally%20use%20delegation%0A%3E%20to%20scripts%20to%20create%20more%20expressive%20power%2C%20as%20in%20dh%2C%20not%20to%20subvert%20the%0A%3E%20usual%20norms.%20%20Thus%2C%20I%20don%27t%20think%20the%20situation%20created%20by%20this%20Policy%0A%3E%20requirement%20is%20objectionable%20enough%20to%20overrule%20it%2C%20even%20leaving%20aside%0A%3E%20the%20benefits%20of%20standardising%20on%20a%20Makefile.%0A%3E%20%0A%3E%20I%20will%20admit%20to%20some%20curiosity%20as%20to%20whether%20Josip%20would%20in%20fact%20comply%0A%3E%20with%20this%20ruling%20by%20%22what%20amounts%20to%20trickery%22%2C%20as%20Ian%20puts%20it%2C%20or%0A%3E%20whether%20he%20would%20decide%20to%20do%20something%20that%20more%20developers%20will%20be%0A%3E%20familiar%20with%20instead.%0A%3E%20%0A%3E%20Had%20I%20spent%20more%20time%20thinking%20about%20this%2C%20I%20might%20have%20tried%20to%0A%3E%20articulate%20a%20position%20for%20the%20ballot%20in%20which%20delegating%20implementation%0A%3E%20of%20debian%2Frules%20to%20scripts%20is%20permitted%20provided%20that%20the%20intent%20of%20such%0A%3E%20scripts%20is%20to%20create%20an%20abstraction%20layer%20that%20could%20be%20used%20by%20multiple%0A%3E%20packages%2C%20which%20would%20distinguish%20%22I%20want%20to%20contribute%20a%20new%20packaging%0A%3E%20helper%20tool%20to%20the%20project%22%20from%20%22I%27m%20trying%20to%20work%20around%20this%0A%3E%20requirement%20and%20use%20my%20favourite%20language%20instead%22.%20%20However%2C%20Andreas%20is%0A%3E%20probably%20right%20in%20pointing%20out%20that%20the%20technical%20committee%20is%20not%20the%0A%3E%20place%20to%20do%20detailed%20policy%20design.%20%20If%20Ian%20feels%20that%20this%20would%20be%20a%0A%3E%20useful%20middle%20ground%20between%20our%20positions%2C%20I%27d%20be%20happy%20to%20take%0A%3E%20something%20like%20this%20to%20-policy%20and%20we%20can%20hash%20it%20out%20there.%0A%3E%20%0A%3E%20--%20%0A%3E%20Colin%20Watson%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%5Bcjwatson%40debian.org%5D%0A&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%20%3C20120331171153.GB12270%40riva.dynamic.greenend.org.uk%3E&In-Reply-To=%3C20120331171153.GB12270%40riva.dynamic.greenend.org.uk%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=cjwatson%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Sat, 31 Mar 2012 18:11:53 +0100</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=137">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">On Sun, Mar 18, 2012 at 09:30:47PM -0700, Russ Allbery wrote: > My impression is that discussion on this bug has wound down, and that it's > unlikely that any new information is going to come up. To me, that > implies that we should call for a vote. I'm pretty sure I'm unconstitutionally late for this, sorry (I've had a busy week and have not been checking Debian mail much). But just in case it matters: > Based on Ian's last response, I think the ballot has two options plus > further discussion, since I'm quite sure that we're not going to outlaw > dh: > > A. debian/rules is not required to be a makefile, only to implement the > same interface as a debian/rules file implemented as a makefile > (including handling of arguments and exit status). Debian Policy > should be updated to change the requirement to a recommendation, and > new versions of the leave package should be permitted to be uploaded to > the archive without changing debian/rules to be a makefile. > > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. > > C. Further discussion. I vote BAC. While I understand the position that B can lead to pathological results, in practice I'm not aware of this happening in practice, or if it is then it's a trivial number of cases; developers generally use delegation to scripts to create more expressive power, as in dh, not to subvert the usual norms. Thus, I don't think the situation created by this Policy requirement is objectionable enough to overrule it, even leaving aside the benefits of standardising on a Makefile. I will admit to some curiosity as to whether Josip would in fact comply with this ruling by "what amounts to trickery", as Ian puts it, or whether he would decide to do something that more developers will be familiar with instead. Had I spent more time thinking about this, I might have tried to articulate a position for the ballot in which delegating implementation of debian/rules to scripts is permitted provided that the intent of such scripts is to create an abstraction layer that could be used by multiple packages, which would distinguish "I want to contribute a new packaging helper tool to the project" from "I'm trying to work around this requirement and use my favourite language instead". However, Andreas is probably right in pointing out that the technical committee is not the place to do detailed policy design. If Ian feels that this would be a useful middle ground between our positions, I'd be happy to take something like this to -policy and we can hash it out there. -- Colin Watson [cjwatson@debian.org] </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;filename=signature.asc;msg=137">signature.asc</a> (application/pgp-signature, inline)]</pre> <div class="infmessage"><hr><p> <a name="138"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 05 Apr 2012 23:21:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=139">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=139">mbox</a>, <a href="#138">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="140"></a>   <strong>Acknowledgement sent</strong> to <code>Russ Allbery <rra@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 05 Apr 2012 23:21:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=141">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=141">mbox</a>, <a href="#140">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="142"></a><a name="msg142"></a><a href="#142">Message #142</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=142">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=142">mbox</a>, <a href="mailto:640874@bugs.debian.org?In-Reply-To=%3C87vcld93cf.fsf%40windlord.stanford.edu%3E&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%20%3C87vcld93cf.fsf%40windlord.stanford.edu%3E&body=On%20Thu%2C%2005%20Apr%202012%2016%3A16%3A32%20-0700%20Russ%20Allbery%20%3Crra%40debian.org%3E%20wrote%3A%0A%3E%20Russ%20Allbery%20%3Crra%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%20Based%20on%20Ian%27s%20last%20response%2C%20I%20think%20the%20ballot%20has%20two%20options%20plus%0A%3E%20%3E%20further%20discussion%2C%20since%20I%27m%20quite%20sure%20that%20we%27re%20not%20going%20to%20outlaw%0A%3E%20%3E%20dh%3A%0A%3E%20%0A%3E%20%3E%20A.%20debian%2Frules%20is%20not%20required%20to%20be%20a%20makefile%2C%20only%20to%20implement%20the%0A%3E%20%3E%20%20%20%20same%20interface%20as%20a%20debian%2Frules%20file%20implemented%20as%20a%20makefile%0A%3E%20%3E%20%20%20%20%28including%20handling%20of%20arguments%20and%20exit%20status%29.%20%20Debian%20Policy%0A%3E%20%3E%20%20%20%20should%20be%20updated%20to%20change%20the%20requirement%20to%20a%20recommendation%2C%20and%0A%3E%20%3E%20%20%20%20new%20versions%20of%20the%20leave%20package%20should%20be%20permitted%20to%20be%20uploaded%20to%0A%3E%20%3E%20%20%20%20the%20archive%20without%20changing%20debian%2Frules%20to%20be%20a%20makefile.%0A%3E%20%0A%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20%3E%20C.%20Further%20discussion.%0A%3E%20%0A%3E%20At%20the%20conclusion%20of%20our%20standard%20voting%20period%20of%20one%20week%2C%20there%20were%0A%3E%20three%20votes%20of%20BAC%20and%20one%20vote%20of%20AB.%20%20%28One%20additional%20vote%20of%20BAC%20came%0A%3E%20in%20after%20the%20voting%20period%20had%20ended.%29%0A%3E%20%0A%3E%20As%20this%20is%2C%20depending%20on%20how%20one%20looks%20at%20it%2C%20a%20conflict%20between%20a%0A%3E%20maintainer%20and%20ftp-master%20policy%20or%20a%20maintainer%20and%20the%20current%0A%3E%20requirements%20of%20Debian%20Policy%2C%20I%20don%27t%20believe%20the%203%3A1%20super-majority%0A%3E%20requirement%20applies%20here%20and%20the%20ballot%20should%20be%20decided%20by%20simple%0A%3E%20majority%20rule.%0A%3E%20%0A%3E%20I%20don%27t%20have%20the%20tools%20available%20to%20me%20at%20the%20moment%20to%20do%20the%20full%20voting%0A%3E%20procedure%2C%20but%20I%27m%20fairly%20sure%20from%20those%20votes%20that%20B%20is%20the%20winning%0A%3E%20option.%20%20I%27d%20like%20someone%20else%20could%20double-check%20me%20on%20that%20and%20confirm%2C%0A%3E%20and%20then%20we%20can%20close%20this%20bug%2C%20deciding%20on%20option%20B.%0A%3E%20%0A%3E%20--%20%0A%3E%20Russ%20Allbery%20%28rra%40debian.org%29%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Chttp%3A%2F%2Fwww.eyrie.org%2F~eagle%2F%3E%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=rra%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Russ Allbery <rra@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Cc:</span> Josip Rodin <joy@debbugs.entuzijast.net></div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 05 Apr 2012 16:16:32 -0700</div> </div> <pre class="message">Russ Allbery <rra@debian.org> writes: > Based on Ian's last response, I think the ballot has two options plus > further discussion, since I'm quite sure that we're not going to outlaw > dh: > A. debian/rules is not required to be a makefile, only to implement the > same interface as a debian/rules file implemented as a makefile > (including handling of arguments and exit status). Debian Policy > should be updated to change the requirement to a recommendation, and > new versions of the leave package should be permitted to be uploaded to > the archive without changing debian/rules to be a makefile. > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. > C. Further discussion. At the conclusion of our standard voting period of one week, there were three votes of BAC and one vote of AB. (One additional vote of BAC came in after the voting period had ended.) As this is, depending on how one looks at it, a conflict between a maintainer and ftp-master policy or a maintainer and the current requirements of Debian Policy, I don't believe the 3:1 super-majority requirement applies here and the ballot should be decided by simple majority rule. I don't have the tools available to me at the moment to do the full voting procedure, but I'm fairly sure from those votes that B is the winning option. I'd like someone else could double-check me on that and confirm, and then we can close this bug, deciding on option B. -- Russ Allbery (rra@debian.org) <<a href="http://www.eyrie.org/~eagle/">http://www.eyrie.org/~eagle/</a>> </pre> <div class="msgreceived"><hr><p> <a name="143"></a>   <strong>Reply sent</strong> to <code>Don Armstrong <don@debian.org></code>:<br> You have taken responsibility. (Wed, 25 Apr 2012 19:45:18 GMT) (<a href="bugreport.cgi?bug=640874;msg=144">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=144">mbox</a>, <a href="#143">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="145"></a>   <strong>Notification sent</strong> to <code>Niels Thykier <niels@thykier.net></code>:<br> Bug acknowledged by developer. (Wed, 25 Apr 2012 19:45:18 GMT) (<a href="bugreport.cgi?bug=640874;msg=146">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=146">mbox</a>, <a href="#145">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="147"></a><a name="msg147"></a><a href="#147">Message #147</a> received at 640874-done@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=147">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=147">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Wed%2C%2025%20Apr%202012%2012%3A42%3A08%20-0700%20Don%20Armstrong%20%3Cdon%40debian.org%3E%20wrote%3A%0A%3E%20The%20result%20of%20this%20decision%20is%20B%3A%0A%3E%20%0A%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20%0A%3E%20Don%20Armstrong%0A%3E%20%0A%3E%20--%20%0A%3E%20PowerPoint%20is%20symptomatic%20of%20a%20certain%20type%20of%20bureaucratic%0A%3E%20environment%3A%20one%20typified%20by%20interminable%20presentations%20with%20lots%20of%0A%3E%20fussy%20little%20bullet-points%20and%20flashy%20dissolves%20and%20soundtracks%20masked%0A%3E%20into%20the%20background%2C%20to%20try%20to%20convince%20the%20audience%20that%20the%20goon%0A%3E%20behind%20the%20computer%20has%20something%20significant%20to%20say.%0A%3E%20%20--%20Charles%20Stross%20_The%20Jennifer%20Morgue_%20p33%0A%3E%20%0A%3E%20http%3A%2F%2Fwww.donarmstrong.com%20%20%20%20%20%20%20%20%20%20%20%20%20%20http%3A%2F%2Frzlab.ucr.edu%0A%3E%20%0A%3E%20%0A%3E%20%0A&subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&References=%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3C87ipi1p5zc.fsf%40windlord.stanford.edu%3E%0A%20%3C87vcld93cf.fsf%40windlord.stanford.edu%3E%0A%20%3C20120425194208.GK3458%40rzlab.ucr.edu%3E&In-Reply-To=%3C20120425194208.GK3458%40rzlab.ucr.edu%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=don%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Don Armstrong <don@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874-done@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Wed, 25 Apr 2012 12:42:08 -0700</div> </div> <pre class="message">The result of this decision is B: B. The Technical Committee affirms the Debian Policy requirement that debian/rules must be a makefile. All packages in the archive, including leave, are required to follow this requirement. This makefile may, as is common practice, delegate implementation of its targets to a script. Don Armstrong -- PowerPoint is symptomatic of a certain type of bureaucratic environment: one typified by interminable presentations with lots of fussy little bullet-points and flashy dissolves and soundtracks masked into the background, to try to convince the audience that the goon behind the computer has something significant to say. -- Charles Stross _The Jennifer Morgue_ p33 <a href="http://www.donarmstrong.com">http://www.donarmstrong.com</a> <a href="http://rzlab.ucr.edu">http://rzlab.ucr.edu</a> </pre> <div class="msgreceived"><hr><p> <a name="148"></a>       <strong>Bug archived.</strong> Request was from <code>Debbugs Internal Request <owner@bugs.debian.org></code> to <code>internal_control@bugs.debian.org</code>. (Thu, 24 May 2012 07:39:57 GMT) (<a href="bugreport.cgi?bug=640874;msg=149">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=149">mbox</a>, <a href="#148">link</a>).</p></p></div> <div class="msgreceived"><hr><p> <a name="150"></a>       <strong>Bug unarchived.</strong> Request was from <code>Colin Watson <cjwatson@debian.org></code> to <code>control@bugs.debian.org</code>. (Thu, 27 Sep 2012 15:54:07 GMT) (<a href="bugreport.cgi?bug=640874;msg=151">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=151">mbox</a>, <a href="#150">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="152"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Technical Committee <debian-ctte@lists.debian.org></code>:<br> <code>Bug#640874</code>; Package <code>tech-ctte</code>. (Thu, 27 Sep 2012 16:15:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=153">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=153">mbox</a>, <a href="#152">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="154"></a>   <strong>Acknowledgement sent</strong> to <code>Colin Watson <cjwatson@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Technical Committee <debian-ctte@lists.debian.org></code>. (Thu, 27 Sep 2012 16:15:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=155">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=155">mbox</a>, <a href="#154">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="156"></a><a name="msg156"></a><a href="#156">Message #156</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=156">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=156">mbox</a>, <a href="mailto:640874@bugs.debian.org?References=%3C20120425194208.GK3458%40rzlab.ucr.edu%3E%0A%20%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%20%3Chandler.640874.D640874.13353829311241.notifdone%40bugs.debian.org%3E%0A%20%3C20120927161258.GA24645%40riva.dynamic.greenend.org.uk%3E&In-Reply-To=%3C20120927161258.GA24645%40riva.dynamic.greenend.org.uk%3E&subject=Re%3A%20Bug%23640874%20closed%20by%20Don%20Armstrong%20%3Cdon%40debian.org%3E%20%28Re%3A%0A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile%29&body=On%20Thu%2C%2027%20Sep%202012%2017%3A12%3A58%20%2B0100%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20wrote%3A%0A%3E%20reassign%20640874%20leave%0A%3E%20reopen%20640874%0A%3E%20thanks%0A%3E%20%0A%3E%20On%20Wed%2C%20Apr%2025%2C%202012%20at%2007%3A45%3A18PM%20%2B0000%2C%20Debian%20Bug%20Tracking%20System%20wrote%3A%0A%3E%20%3E%20Date%3A%20Wed%2C%2025%20Apr%202012%2012%3A42%3A08%20-0700%0A%3E%20%3E%20From%3A%20Don%20Armstrong%20%3Cdon%40debian.org%3E%0A%3E%20%3E%20To%3A%20640874-done%40bugs.debian.org%0A%3E%20%3E%20Subject%3A%20Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile%0A%3E%20%3E%20User-Agent%3A%20Mutt%2F1.5.21%20%282010-09-15%29%0A%3E%20%3E%20%0A%3E%20%3E%20The%20result%20of%20this%20decision%20is%20B%3A%0A%3E%20%3E%20%0A%3E%20%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%0A%3E%20I%27m%20reopening%20this%20bug%20and%20reassigning%20back%20to%20leave%20for%20implementation%0A%3E%20of%20this%20TC%20resolution%2C%20since%20it%20seems%20to%20have%20been%20lost%20somewhat.%0A%3E%20%0A%3E%20Thanks%2C%0A%3E%20%0A%3E%20--%20%0A%3E%20Colin%20Watson%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%5Bcjwatson%40debian.org%5D%0A%3E%20%0A%3E%20%0A">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=cjwatson%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Colin Watson <cjwatson@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874 closed by Don Armstrong <don@debian.org> (Re: Bug#640874: leave: debian/rules is not a Makefile)</div> <div class="header"><span class="headerfield">Date:</span> Thu, 27 Sep 2012 17:12:58 +0100</div> </div> <pre class="message">reassign 640874 leave reopen 640874 thanks On Wed, Apr 25, 2012 at 07:45:18PM +0000, Debian Bug Tracking System wrote: > Date: Wed, 25 Apr 2012 12:42:08 -0700 > From: Don Armstrong <don@debian.org> > To: 640874-done@bugs.debian.org > Subject: Re: Bug#640874: leave: debian/rules is not a Makefile > User-Agent: Mutt/1.5.21 (2010-09-15) > > The result of this decision is B: > > B. The Technical Committee affirms the Debian Policy requirement that > debian/rules must be a makefile. All packages in the archive, > including leave, are required to follow this requirement. This > makefile may, as is common practice, delegate implementation of its > targets to a script. I'm reopening this bug and reassigning back to leave for implementation of this TC resolution, since it seems to have been lost somewhat. Thanks, -- Colin Watson [cjwatson@debian.org] </pre> <div class="msgreceived"><hr><p> <a name="157"></a>       <strong>Bug reassigned from package '<a href="pkgreport.cgi?package=tech-ctte">tech-ctte</a>' to '<a href="pkgreport.cgi?package=leave">leave</a>'.</strong> Request was from <code>Colin Watson <cjwatson@debian.org></code> to <code>control@bugs.debian.org</code>. (Thu, 27 Sep 2012 16:15:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=158">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=158">mbox</a>, <a href="#157">link</a>).</p></p></div> <div class="msgreceived"><hr><p> <a name="159"></a>       <strong>Bug reopened</strong> Request was from <code>Colin Watson <cjwatson@debian.org></code> to <code>control@bugs.debian.org</code>. (Thu, 27 Sep 2012 16:15:05 GMT) (<a href="bugreport.cgi?bug=640874;msg=160">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=160">mbox</a>, <a href="#159">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="161"></a>   <strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Josip Rodin <joy-packages@debian.org></code>:<br> <code>Bug#640874</code>; Package <code>leave</code>. (Thu, 11 Oct 2012 19:57:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=162">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=162">mbox</a>, <a href="#161">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="163"></a>   <strong>Acknowledgement sent</strong> to <code>Sébastien Villemot <sebastien@debian.org></code>:<br> Extra info received and forwarded to list. Copy sent to <code>Josip Rodin <joy-packages@debian.org></code>. (Thu, 11 Oct 2012 19:57:03 GMT) (<a href="bugreport.cgi?bug=640874;msg=164">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=164">mbox</a>, <a href="#163">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="165"></a><a name="msg165"></a><a href="#165">Message #165</a> received at 640874@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=165">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=165">mbox</a>, <a href="mailto:640874@bugs.debian.org?subject=Re%3A%20Bug%23640874%3A%20leave%3A%20debian%2Frules%20is%20not%20a%20Makefile&body=On%20Thu%2C%2011%20Oct%202012%2021%3A54%3A16%20%2B0200%20%3D%3Futf-8%3FQ%3FS%3DC3%3DA9bastien_Villemot%3F%3D%20%3Csebastien%40debian.org%3E%20wrote%3A%0A%3E%20Dear%20Maintainer%2C%0A%3E%20%0A%3E%20Colin%20Watson%20%3Ccjwatson%40debian.org%3E%20writes%3A%0A%3E%20%0A%3E%20%3E%20On%20Wed%2C%20Apr%2025%2C%202012%20at%2007%3A45%3A18PM%20%2B0000%2C%20Debian%20Bug%20Tracking%20System%20wrote%3A%0A%3E%20%0A%3E%20%3E%3E%20B.%20The%20Technical%20Committee%20affirms%20the%20Debian%20Policy%20requirement%20that%0A%3E%20%3E%3E%20%20%20%20debian%2Frules%20must%20be%20a%20makefile.%20%20All%20packages%20in%20the%20archive%2C%0A%3E%20%3E%3E%20%20%20%20including%20leave%2C%20are%20required%20to%20follow%20this%20requirement.%20%20This%0A%3E%20%3E%3E%20%20%20%20makefile%20may%2C%20as%20is%20common%20practice%2C%20delegate%20implementation%20of%20its%0A%3E%20%3E%3E%20%20%20%20targets%20to%20a%20script.%0A%3E%20%3E%0A%3E%20%3E%20I%27m%20reopening%20this%20bug%20and%20reassigning%20back%20to%20leave%20for%20implementation%0A%3E%20%3E%20of%20this%20TC%20resolution%2C%20since%20it%20seems%20to%20have%20been%20lost%20somewhat.%0A%3E%20%0A%3E%20I%20have%20uploaded%20to%20DELAYED%2F5%20an%20NMU%20of%20leave%20versioned%201.12-2.1%20which%0A%3E%20fixes%20this%20issue.%20I%20have%20tried%20to%20preserve%20as%20much%20as%20possible%20the%0A%3E%20structure%20of%20the%20original%20shell%20script.%20The%20debdiff%20is%20attached.%20Don%27t%0A%3E%20hesitate%20to%20tell%20me%20if%20I%20should%20delay%20the%20upload%20longer.%0A%3E%20%0A%3E%20Regards%2C%0A&References=%3C20120425194208.GK3458%40rzlab.ucr.edu%3E%0A%09%3C20110908062132.4675.33966.reportbug%40getsu.thykier.net%3E%0A%09%3Chandler.640874.D640874.13353829311241.notifdone%40bugs.debian.org%3E%0A%09%3C20120927161258.GA24645%40riva.dynamic.greenend.org.uk%3E%0A%20%3C87zk3su6mv.fsf_-_%40brouzouf.villemot.name%3E&In-Reply-To=%3C87zk3su6mv.fsf_-_%40brouzouf.villemot.name%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=sebastien%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Sébastien Villemot <sebastien@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Re: Bug#640874: leave: debian/rules is not a Makefile</div> <div class="header"><span class="headerfield">Date:</span> Thu, 11 Oct 2012 21:54:16 +0200</div> </div> <pre class="mime">[<a href="bugreport.cgi?att=0;bug=640874;msg=165">Message part 1</a> (text/plain, inline)]</pre> <pre class="message">Dear Maintainer, Colin Watson <cjwatson@debian.org> writes: > On Wed, Apr 25, 2012 at 07:45:18PM +0000, Debian Bug Tracking System wrote: >> B. The Technical Committee affirms the Debian Policy requirement that >> debian/rules must be a makefile. All packages in the archive, >> including leave, are required to follow this requirement. This >> makefile may, as is common practice, delegate implementation of its >> targets to a script. > > I'm reopening this bug and reassigning back to leave for implementation > of this TC resolution, since it seems to have been lost somewhat. I have uploaded to DELAYED/5 an NMU of leave versioned 1.12-2.1 which fixes this issue. I have tried to preserve as much as possible the structure of the original shell script. The debdiff is attached. Don't hesitate to tell me if I should delay the upload longer. Regards, </pre> <pre class="mime">[<a href="bugreport.cgi?att=1;bug=640874;filename=bug640874.patch;msg=165">bug640874.patch</a> (text/x-diff, attachment)]</pre> <pre class="mime">[<a href="bugreport.cgi?att=2;bug=640874;msg=165">Message part 3</a> (text/plain, inline)]</pre> <pre class="message wrapping"> -- .''`. Sébastien Villemot : :' : Debian Developer `. `' <a href="http://www.dynare.org/sebastien">http://www.dynare.org/sebastien</a> `- GPG Key: 4096R/381A7594 </pre> <pre class="mime">[<a href="bugreport.cgi?att=3;bug=640874;msg=165">Message part 4</a> (application/pgp-signature, inline)]</pre> <div class="msgreceived"><hr><p> <a name="166"></a>       <strong>Added tag(s) pending and patch.</strong> Request was from <code>Sébastien Villemot <sebastien@debian.org></code> to <code>control@bugs.debian.org</code>. (Thu, 11 Oct 2012 20:00:10 GMT) (<a href="bugreport.cgi?bug=640874;msg=167">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=167">mbox</a>, <a href="#166">link</a>).</p></p></div> <div class="msgreceived"><hr><p> <a name="168"></a>   <strong>Reply sent</strong> to <code>Sébastien Villemot <sebastien@debian.org></code>:<br> You have taken responsibility. (Tue, 16 Oct 2012 20:48:08 GMT) (<a href="bugreport.cgi?bug=640874;msg=169">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=169">mbox</a>, <a href="#168">link</a>).</p></p></div> <div class="infmessage"><hr><p> <a name="170"></a>   <strong>Notification sent</strong> to <code>Niels Thykier <niels@thykier.net></code>:<br> Bug acknowledged by developer. (Tue, 16 Oct 2012 20:48:08 GMT) (<a href="bugreport.cgi?bug=640874;msg=171">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=171">mbox</a>, <a href="#170">link</a>).</p></p></div> <hr><p class="msgreceived"><a name="172"></a><a name="msg172"></a><a href="#172">Message #172</a> received at 640874-close@bugs.debian.org (<a href="bugreport.cgi?bug=640874;msg=172">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=172">mbox</a>, <a href="mailto:640874@bugs.debian.org?body=On%20Tue%2C%2016%20Oct%202012%2020%3A47%3A45%20%2B0000%20%3D%3Futf-8%3Fq%3FS%3DC3%3DA9bastien_Villemot%3F%3D%20%3Csebastien%40debian.org%3E%20wrote%3A%0A%3E%20Source%3A%20leave%0A%3E%20Source-Version%3A%201.12-2.1%0A%3E%20%0A%3E%20We%20believe%20that%20the%20bug%20you%20reported%20is%20fixed%20in%20the%20latest%20version%20of%0A%3E%20leave%2C%20which%20is%20due%20to%20be%20installed%20in%20the%20Debian%20FTP%20archive.%0A%3E%20%0A%3E%20A%20summary%20of%20the%20changes%20between%20this%20version%20and%20the%20previous%20one%20is%0A%3E%20attached.%0A%3E%20%0A%3E%20Thank%20you%20for%20reporting%20the%20bug%2C%20which%20will%20now%20be%20closed.%20%20If%20you%0A%3E%20have%20further%20comments%20please%20address%20them%20to%20640874%40bugs.debian.org%2C%0A%3E%20and%20the%20maintainer%20will%20reopen%20the%20bug%20report%20if%20appropriate.%0A%3E%20%0A%3E%20Debian%20distribution%20maintenance%20software%0A%3E%20pp.%0A%3E%20S%C3%A9bastien%20Villemot%20%3Csebastien%40debian.org%3E%20%28supplier%20of%20updated%20leave%20package%29%0A%3E%20%0A%3E%20%28This%20message%20was%20generated%20automatically%20at%20their%20request%3B%20if%20you%0A%3E%20believe%20that%20there%20is%20a%20problem%20with%20it%20please%20contact%20the%20archive%0A%3E%20administrators%20by%20mailing%20ftpmaster%40debian.org%29%0A%3E%20%0A%3E%20%0A%3E%20-----BEGIN%20PGP%20SIGNED%20MESSAGE-----%0A%3E%20Hash%3A%20SHA256%0A%3E%20%0A%3E%20Format%3A%201.8%0A%3E%20Date%3A%20Thu%2C%2011%20Oct%202012%2021%3A23%3A51%20%2B0200%0A%3E%20Source%3A%20leave%0A%3E%20Binary%3A%20leave%0A%3E%20Architecture%3A%20source%20amd64%0A%3E%20Version%3A%201.12-2.1%0A%3E%20Distribution%3A%20unstable%0A%3E%20Urgency%3A%20low%0A%3E%20Maintainer%3A%20Josip%20Rodin%20%3Cjoy-packages%40debian.org%3E%0A%3E%20Changed-By%3A%20S%C3%A9bastien%20Villemot%20%3Csebastien%40debian.org%3E%0A%3E%20Description%3A%20%0A%3E%20%20leave%20%20%20%20%20%20-%20Reminds%20you%20when%20you%20have%20to%20leave%0A%3E%20Closes%3A%20640874%0A%3E%20Changes%3A%20%0A%3E%20%20leave%20%281.12-2.1%29%20unstable%3B%20urgency%3Dlow%0A%3E%20%20.%0A%3E%20%20%20%20%2A%20Non-maintainer%20upload.%0A%3E%20%20%20%20%2A%20Convert%20debian%2Frules%20to%20a%20Makefile%20%28Closes%3A%20%23640874%29%0A%3E%20Checksums-Sha1%3A%20%0A%3E%20%2034bb5fad81033304f6c39407b7a3e9cb27427920%201574%20leave_1.12-2.1.dsc%0A%3E%20%20f8387f5c04c6082877a140be0f788829f3ad19ce%203043%20leave_1.12-2.1.diff.gz%0A%3E%20%20f6cd6c47a2b0371cab310e8dca3d2e64c77313b8%207762%20leave_1.12-2.1_amd64.deb%0A%3E%20Checksums-Sha256%3A%20%0A%3E%20%2067ce99a9b2323decbc55270a933fa7b365a0ab8be9f36248c67e2b1f0397b142%201574%20leave_1.12-2.1.dsc%0A%3E%20%205e05d20357881e73c907b66716865e351b6e4e0e80eef472ff0dbe306abe19b5%203043%20leave_1.12-2.1.diff.gz%0A%3E%20%20b849764336a92d78e0cb755f9a495e3731ac8a9d42e0ef782acdf7ddee9b677d%207762%20leave_1.12-2.1_amd64.deb%0A%3E%20Files%3A%20%0A%3E%20%20c88e21cae6861153e8a4ac763ddb85ad%201574%20utils%20optional%20leave_1.12-2.1.dsc%0A%3E%20%20456ccdd3370402555e79e6cdeccabdd4%203043%20utils%20optional%20leave_1.12-2.1.diff.gz%0A%3E%20%20b0ebdb4d1641c4e9e04fd9ed3a118ed0%207762%20utils%20optional%20leave_1.12-2.1_amd64.deb%0A%3E%20%0A%3E%20-----BEGIN%20PGP%20SIGNATURE-----%0A%3E%20Version%3A%20GnuPG%20v1.4.12%20%28GNU%2FLinux%29%0A%3E%20%0A%3E%20iQIcBAEBCAAGBQJQdyGIAAoJECzs6TUOzr5KRxMP%2F1Vk2lJSLzh%2BLPPtn46F1DRJ%0A&subject=Re%3A%20Bug%23640874%3A%20fixed%20in%20leave%201.12-2.1&In-Reply-To=%3CE1TOE3F-00042m-Qu%40franck.debian.org%3E&References=%3CE1TOE3F-00042m-Qu%40franck.debian.org%3E">reply</a>):</p> <div class="headers"> <img src="/cgi-bin/libravatar.cgi?email=sebastien%40debian.org" alt=""> <div class="header"><span class="headerfield">From:</span> Sébastien Villemot <sebastien@debian.org></div> <div class="header"><span class="headerfield">To:</span> 640874-close@bugs.debian.org</div> <div class="header"><span class="headerfield">Subject:</span> Bug#640874: fixed in leave 1.12-2.1</div> <div class="header"><span class="headerfield">Date:</span> Tue, 16 Oct 2012 20:47:45 +0000</div> </div> <pre class="message">Source: leave Source-Version: 1.12-2.1 We believe that the bug you reported is fixed in the latest version of leave, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 640874@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sébastien Villemot <sebastien@debian.org> (supplier of updated leave package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Thu, 11 Oct 2012 21:23:51 +0200 Source: leave Binary: leave Architecture: source amd64 Version: 1.12-2.1 Distribution: unstable Urgency: low Maintainer: Josip Rodin <joy-packages@debian.org> Changed-By: Sébastien Villemot <sebastien@debian.org> Description: leave - Reminds you when you have to leave Closes: <a href="bugreport.cgi?bug=640874">640874</a> Changes: leave (1.12-2.1) unstable; urgency=low . * Non-maintainer upload. * Convert debian/rules to a Makefile (Closes: #<a href="bugreport.cgi?bug=640874">640874</a>) Checksums-Sha1: 34bb5fad81033304f6c39407b7a3e9cb27427920 1574 leave_1.12-2.1.dsc f8387f5c04c6082877a140be0f788829f3ad19ce 3043 leave_1.12-2.1.diff.gz f6cd6c47a2b0371cab310e8dca3d2e64c77313b8 7762 leave_1.12-2.1_amd64.deb Checksums-Sha256: 67ce99a9b2323decbc55270a933fa7b365a0ab8be9f36248c67e2b1f0397b142 1574 leave_1.12-2.1.dsc 5e05d20357881e73c907b66716865e351b6e4e0e80eef472ff0dbe306abe19b5 3043 leave_1.12-2.1.diff.gz b849764336a92d78e0cb755f9a495e3731ac8a9d42e0ef782acdf7ddee9b677d 7762 leave_1.12-2.1_amd64.deb Files: c88e21cae6861153e8a4ac763ddb85ad 1574 utils optional leave_1.12-2.1.dsc 456ccdd3370402555e79e6cdeccabdd4 3043 utils optional leave_1.12-2.1.diff.gz b0ebdb4d1641c4e9e04fd9ed3a118ed0 7762 utils optional leave_1.12-2.1_amd64.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQdyGIAAoJECzs6TUOzr5KRxMP/1Vk2lJSLzh+LPPtn46F1DRJ bcL9+y5hkinTGtzQy3unS5St1wwPGfpy+yGmxeSnxOCgnMZiYTTlIpUWwzQyVFNd Y2GD6r4B8OjHtfo9gT03oxMbf2z9JmNkKvEPVh7XM/PHz3/3b12zOGT5/4yCUnee rdVGEoTkNYWfhNumPZVZ9qe/w7vXG61JmNpXSD0/FgLoptzKOimXpen0ReJoiX6K ZEE08DFGdrXjJCRnx3kzZk8MvHAkPIZSJjhakwXv5qfBQ/PWuza2nW3nhj+J+8aP T0KteoJqHoiYO9zQOdpBdYbKcA7b8FTdVN777f3oZtraQPn3FRW26MNM6YtU2eSc rmP+v0KtulCzC4PjAQfgVqi0iitiF4EKScReWA4djodE1LTPdxIUIw4X/BMSI/JM aLlgiRegWJZKvaYacbyd5owZjzAja56qtInaDg79Hn6dEZqkGq9Km+2eV68Oi90b 55AV1cbDB21L70C0qkKw6hVtGLW7VWzeL6RaNkL0DW4Ou4EIigFXeN3nTb+pHYfR JUgKFQoWqeUn2YqpQBo0a5Y0zQwjHPkv5lHQEOP6QIVEUzUQEwpznNScxK+84fhQ dTjt3DS99tvc2HyUTDqMsA3vFlSWl6Br0uxXgopMu4u4l+eG59m48RFqqQI6VnvT XuSWHKchgQJNQX4NvgZi =+lhM -----END PGP SIGNATURE----- </pre> <div class="msgreceived"><hr><p> <a name="173"></a>       <strong>Bug archived.</strong> Request was from <code>Debbugs Internal Request <owner@bugs.debian.org></code> to <code>internal_control@bugs.debian.org</code>. (Sun, 02 Jun 2013 08:15:25 GMT) (<a href="bugreport.cgi?bug=640874;msg=174">full text</a>, <a href="bugreport.cgi?bug=640874;mbox=yes;msg=174">mbox</a>, <a href="#173">link</a>).</p></p></div> <hr> <p class="msgreceived">Send a report that <a href="https://bugs.debian.org/cgi-bin/bugspam.cgi?bug=640874">this bug log contains spam</a>.</p> <hr> <ADDRESS>Debian bug tracking system administrator <<A HREF="mailto:owner@bugs.debian.org">owner@bugs.debian.org</A>>. Last modified: Mon Dec 2 22:00:10 2024; Machine Name: bembo <P> <A HREF="https://www.debian.org/Bugs/">Debian Bug tracking system</A> </p> <p> Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from <a href="https://bugs.debian.org/debbugs-source/">https://bugs.debian.org/debbugs-source/</a>. </p> <p> Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors. </p> </ADDRESS> </body> </html>