Re: debian/rules make -f restriction
Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit : The interface definition behind this is: That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates it is not the interface. [...] For the sake of completeness: Policy states that debian/rules is a makefile. There is no need to document the above because all the make manuals already do so. Best, Michael pgpuyS4YjbprL.pgp Description: PGP signature
Re: debian/rules make -f restriction
Tobi listacco...@e-tobi.net writes: /usr/share/vdr-dev/dependencies.sh. But the shebang simply is nothing to worry about. May I ask what's the reason you're using this kind of a convoluted system? Wouldn't it be simpler to separate debian/make-special-vdr.sh and debian/rules, and call debian/make-special-vdr.sh directly when the special cases are needed? debian/rules is a specific interface for Debian building, why are you using that same interface for other purposes? -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Kalle Kivimaa wrote: the special cases are needed? debian/rules is a specific interface for Debian building, why are you using that same interface for other purposes? It's just because we believe this is the easiest to use and easiest to maintain way to do this: Build a standard vdr-plugin-* package: dpkg-buildpackage -tc -uc -us -rfakeroot Build a development version of the vdr-plugin-* package from the same source, but using the API of the development version of VDR and with a different binary package name: SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot This way it works out-of-the-box with all the various build tools. From our point of view this is so easy to do and so easy to maintain (it's working quite well for over 2 years now), that this very specific requirement of the policy just seems to be a useless piece of bureaucratic over-specificiation. We are still thinking about different solutions, not requiring to change the shebang line. But as said before - it's not that easy and it will most likely increase the complexity of debian/rules. A lot of pain, without a gain :-) @all: Please don't feel offended because I question the policy here. It's not because I don't like the policy, it's because I care about it! Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
[...] Build a development version of the vdr-plugin-* package from the same source, but using the API of the development version of VDR and with a different binary package name: SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot This way it works out-of-the-box with all the various build tools. Why don't you provide a script like debian/make-special-rules such that debian/make-special-rules dpkg-buildpackage -tc -uc -us -rfakeroot does the job? I'm sure you already considered this idea, so would you mind explaining why this does not work? Obviously you can tell your users/developers that calling this script is required just as you documented the SPECIAL_VDR_SUFFIX thingy. From our point of view this is so easy to do and so easy to maintain (it's working quite well for over 2 years now), that this very specific requirement of the policy just seems to be a useless piece of bureaucratic over-specificiation. We are still thinking about different solutions, not requiring to change the shebang line. But as said before - it's not that easy and it will most likely increase the complexity of debian/rules. A lot of pain, without a gain :-) [...] I think Manoj already explained quite well why policy is that specific about a single line. And apparently thousands of packages adhere to policy in this case, so it's somewhat dubious that only VDR-related packages cannot cope with it. I understand that any solution must remain easy to use and of course also easy to maintain. But a hackish shebang line cannot be the only way to achieve this. Best, Michael pgpXE7xLSaUKN.pgp Description: PGP signature
Re: debian/rules make -f restriction
* Tobi listacco...@e-tobi.net [091030 10:55]: From our point of view this is so easy to do and so easy to maintain (it's working quite well for over 2 years now), that this very specific requirement of the policy just seems to be a useless piece of bureaucratic over-specificiation. That is your point of view. From my point of view it is so horrible a kludge that I am happy policy is forbidding it explicitly. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Michael Tautschnig schrieb: I think Manoj already explained quite well why policy is that specific about a single line. And I explaind why the policy is over specific in this case :-) The modified shebang line didn't had any drawback in the past and wouldn't have any drawback in the future. But it's not worth discussing this anymore. I think everything was said. We will try to find a different way to tackle this problem - it just hurts to throw away a nice working solution. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Build a standard vdr-plugin-* package: dpkg-buildpackage -tc -uc -us -rfakeroot Build a development version of the vdr-plugin-* package from the same source, but using the API of the development version of VDR and with a different binary package name: SPECIAL_VDR_SUFFIX=devel dpkg-buildpackage -tc -uc -us -rfakeroot This way it works out-of-the-box with all the various build tools. And what is stopping you from doing that with a proper makefile? You are constantly repeating you need to violate policy for an issue that is similar easy to achieve while still following the policy. You can use standard make syntax on deciding if you build a policy compliant package or if you are going to do mad things to the debian/ before continuing the build, and the actual changes you are doing to debian/rules seem to be easy enough to also achieve with make checking for the environment var or not. -- bye, Joerg A BSP means that many DDs and other mere mortals get together to play xroach. Sadly, that package was removed from Debian some time ago, so they have to squash other bugs (preferably RC) instead. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Fri, Oct 30 2009, Tobi wrote: Michael Tautschnig schrieb: I think Manoj already explained quite well why policy is that specific about a single line. And I explaind why the policy is over specific in this case :-) No. You opined that the policy is over specific, but with little rationale beyond I think this is so. I think that 1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build 2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build 3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build 4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build Giving you differing results is confusing enough to anyone building the packages manually (You know, as free software folks, the buildds are not the sole focus of our packaging) that I think it is good that the policy is specific enough to block these. I think it would be a good idea to _add_ to policy a rule that says that make -f debian/rules and ./debian/rules must behave identically, to prevent confusion, and to promote reproducibility, and conform to the principle of least surprise. manoj -- Imagine what we can imagine! Arthur Rubinstein Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Manoj Srivastava schrieb: 1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build 2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build 3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build 4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build Giving you differing results is confusing enough to anyone building the packages manually (You know, as free software folks, the buildds are not the sole focus of our packaging) that I think it is good that the policy is specific enough to block these. I just don't think this is a problem at all. If you use SPECIAL_VDR_SUFFIX=devel, you do this for a reason. It's very specific for this set of packages and without reading the documentation, you wouldn't even consider setting SPECIAL_VDR_SUFFIX=devel. And if you read the documentation, you know exactly, how to use SPECIAL_VDR_SUFFIX. In general: IMHO the policy shouldn't force implementation details, it should just enforce the interface. But as I wrote earlier: case closed, everything has been said - we will try to come up with another solution to satisfy the policy, even if it is uglier and requires some more brain cycles to be understood. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Fri, Oct 30 2009, Tobi wrote: Manoj Srivastava schrieb: 1. SPECIAL_VDR_SUFFIX=devel make -f debian/rules build 2. make -f debian/rules SPECIAL_VDR_SUFFIX=devel build 3. SPECIAL_VDR_SUFFIX=devel ./debian/rules build 4. ./debian/rules SPECIAL_VDR_SUFFIX=devel build Giving you differing results is confusing enough to anyone building the packages manually (You know, as free software folks, the buildds are not the sole focus of our packaging) that I think it is good that the policy is specific enough to block these. I just don't think this is a problem at all. If you use SPECIAL_VDR_SUFFIX=devel, you do this for a reason. It's very specific for this set of packages and without reading the documentation, you wouldn't even consider setting SPECIAL_VDR_SUFFIX=devel. And if you read the documentation, you know exactly, how to use SPECIAL_VDR_SUFFIX. Oh, I am doing this for the reasons specified. But I have been assured by policy that it is a makefile, so I think any of the 4 commands will give me the super-duper devel version, right? Wrong! And that is why this is a horrendous idea. In general: IMHO the policy shouldn't force implementation details, it should just enforce the interface. The interface definition behind this is: calling make -f debian/rules and ./debian/rules should result in identical behaviour, all other things being equal. Either invocation should deal identically with the environment, and with variables set on the command line. There. manoj -- Revolution, n.: A form of government abroad. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
[ I haven't looked the vdr-* source; apologies if I miss something essential. ] Tobi wrote: Personally I think debian/rules shouldn't be restriked to make. What happens if you do `./debian/rules -p | less'? Although seldom needed, that's a useful thing when you have to debug the build system, especially when it's intercepted with upstream's and things are not working as one would expect. (I fixed a bug in a package using this technique once, so it's not just a hypothetical argument.) IMHO, the assumption that debian/rules is a makefile (or more precisely, a GNU makefile) has its deep roots in maintainers' minds. Personally, I've never associated it with alleged policy bureaucracy, I've always thought that's simply the *right* thing to do. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Le Fri, Oct 30, 2009 at 09:35:58AM -0500, Manoj Srivastava a écrit : The interface definition behind this is: That ‘make -f debian/rules’ is not present anywhere in the Policy demonstrates it is not the interface. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit : Debian Policy 4.9 says about debian/rules: 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. Dear all, I also do not understand that rule. There are a larger number of packages that are simply removing all the content from the make file, for instance like: [...] I don't think there's a point in disussing whether or not the shebang-line must be there (and that it must read as stated in policy). The fundamental point is that debian/rules must be a Makefile (and not just looks like a Makefile). Debian Policy 4.9 guarantees that the behavior of debian/rules will be the same if called as either make -f debian/rules or simply debian/rules. I think that the key part of the Policy is the interface: debian/rules can be called with arguments such as ‘build’, ‘clean’, etc. When unique features of GNU Make are not needed, I do not see much advantage in requiring that the parts that actually do the work are wrapped into a makefile. Can’t we just trust the maintainers instead of putting restrictions that in the end are only increasing complexity for no benefit? [...] Yes, it's the interface. And the first sentence of 4.9 reads as: 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. This implies that the interface is to a larger extent documented in the make documentation. Policy also specifies that a set of targets must be supported by this makefile, but it doesn't say that these are the (only) supported arguments. What about -j, for example? Not part of 4.9, but supported and documented by make. Adhering to a standard actually decreases complexity. What may seem elegant at first makes it a lot harder for other people to step in. For example, the VDR-solution IMHO doesn't decrease complexity, it merely hides it. Best, Michael pgp7d7EB6nuxy.pgp Description: PGP signature
Re: debian/rules make -f restriction
Am Mittwoch, den 28.10.2009, 19:05 -0500 schrieb Manoj Srivastava: The solution we have right now is in some way elegant, because you have only to deal with a standard debian/rules and besides the different shebang line there's nothing else to care about. Actually, there is. My states makefile can no longer include debian/rules, because, you see, it is not a makefile. There are other ways that it does not look like a makefile, walk like a makefile, or quack like one. I do not see how the shebang-line of debian/rules affects the ability to include debian/rules from other Makefiles, as far as i can see, the the shebang-line would be completely ignored in this case. (Which would result in behaving like it does in the normal Debian build process.) Regards, Thomas -- Thomas Schmidt, Debian VDR Team http://pkg-vdr-dvb.alioth.debian.org/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: debian/rules make -f restriction
On 28/10/09 at 19:05 -0500, Manoj Srivastava wrote: Actually, there is. My states makefile can no longer include debian/rules, because, you see, it is not a makefile. There are other ways that it does not look like a makefile, walk like a makefile, or quack like one. The debian/rules file in the vdr* packages _is_ a makefile. It just doesn't have the shebang line required by policy. I don't think there's anything that prevents you from including it. Also, if SPECIAL_VDR_SUFFIX is not set, /usr/share/vdr-dev/make-special-vdr.sh just calls make -f $@, so I don't see why calling, for example, debian/rules -d clean would not work as expected. It sounds like several people in this discussion are shooting at an easy target without looking at the specific details. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Michael Tautschnig wrote: Adhering to a standard actually decreases complexity. What may seem elegant at first makes it a lot harder for other people to step in. For example, the VDR-solution IMHO doesn't decrease complexity, it merely hides it. Yes, it indeed hides some complexity. But it only hides the stuff that is beyond the scope of the actual standard build process. It has no impact on the maintainability of the packages. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Michael Tautschnig wrote: Adhering to a standard actually decreases complexity. What may seem elegant at first makes it a lot harder for other people to step in. For example, the VDR-solution IMHO doesn't decrease complexity, it merely hides it. Yes, it indeed hides some complexity. But it only hides the stuff that is beyond the scope of the actual standard build process. It has no impact on the maintainability of the packages. In an earlier post you mentioned a pbuilder build process: If that is what you are using, why not go for pbuilder hooks? A hook named Asomething should be fine, as far as I understood. It should get executed after unpacking the source, but before starting the build. You could fiddle around with debian/rules in any way you like and you would (a) not need the special shebang line, (b) not contaminate the package _at all_ and (c) be happy :-) HTH, Michael pgpps4KcO5Q3h.pgp Description: PGP signature
Re: debian/rules make -f restriction
Tobi listacco...@e-tobi.net writes: Fabian Greffrath wrote: Why not so it the other way round, i.e. start two different scripts (or the same script with different parameters) from a debian/rules Makefile depending on the environment variable? Might be possible, but it would require major changes to debian/rules, but our goal is to keep debian/rules as simple as possible without any stuff you wouldn't expect in a Debian package. Before adding any ugly stuff to debian/rules I would rather let an external build script to the dirty work. That's just harder to integrate into our pbuilder build process. Tobias Or verry little (although I probably get crucified for this): mv debian/rules debian/rules-no-make cat debian/rules EOF #! /usr/bin/make -f %: $(MAKE) debian/rules-no-make $@ EOF But I would really go with the idea to include different makefile sniplets depending on your variable directly in the Makefile. You can even be conform and use DEB_BUILD_OPTIONS like many other packages do to allow altered builds. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Michael Tautschnig schrieb: In an earlier post you mentioned a pbuilder build process: If that is what you are using, why not go for pbuilder hooks? This would surely be possible, but then the users compiling their own packages will complain :-) @all: Thanks for your technical suggestions! They surely are worth thinking about. But as far as we can tell, the current solution is still the best. It hides some complex stuff without having any impact on the default debian/rules behaviour. We are maintaining a alot of VDR plugin packages (about 120 at the moment - 26 are official Debian packages), so trust us, that we are very careful when adding any kind of complexity - it's in our own interest to keep the packages as easy maintainable as possible. The whole point of the make-special-vdr thing is to make it easy for us and the users to build and test the current development branch of VDR, so any bugs can be spotted early. The upcoming VDR release includes some major changes and testing it before getting it into Debian is vital. In order to run the VDR package you usually require a DVB card, so most users can test VDR packages only on their production system (if you can call a TV 'productive' :-). This is where the make-special-vdr hooks in and allows to build the main application and plugin packages from the same source, but with a different binary package name, which can be installed side-by-side to the stable productive versions. So to summarize: Our solution gives a wider audience the possibility to test a development version of VDR, with zero impact on the standard build process, but not following the policy word-by-word. So leaving any possible technical workarounds aside: Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? I would say no: debian/rules is still a normal Makefille and it still calls make -f when executed (just indirectly via the make-special-vdr wrapper script). Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Le Thu, Oct 29, 2009 at 08:02:46AM +0100, Michael Tautschnig a écrit : Debian Policy 4.9 guarantees that the behavior of debian/rules will be the same if called as either make -f debian/rules or simply debian/rules. Is there any piece of our infrastructure that needs this feature ? If not, I do not see much benefit enforcing it. As an example, I just downloaded the ‘hello-debhelper’ packages and replaced debian/rules by a symbolic link to /usr/bin/dh. The binary packages built fine with dpkg-buildpackage. (The source packages needed the format 3.0 (quilt), for which good news are expected soon.) The other example you gave, the -j option, is also actually a good example to show that debian/rules does not need to be a makefile (and hence does not need to be callable by ‘make -f’). The Policy interface for parallel building is DEB_BUILD_OPTIONS… To me, this is just another example of how the Policy is sometimes going too far in chosing how developers should implement interfaces, instead of simply specifying the interface. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, 2009-10-29 at 21:35 +0900, Charles Plessy wrote: (The source packages needed the format 3.0 (quilt), for which good news are expected soon.) Already: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457345 -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? As long as you don't have an objection against having serious bugs filed and your packages not be part of a stable Debian release, I guess not. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu Oct 29 15:58, Michael Banck wrote: On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? As long as you don't have an objection against having serious bugs filed and your packages not be part of a stable Debian release, I guess not. put me in the camp that doesn't think this is necessary. If it behaves precisely the same way as a makefile which does have that shbang line when compiling the standard Debian package I really don't think there is a problem with this. I'm also against the suggestion which reduces debian/rules to: ifeq () include real-debian-rules.mk else include alternate-debian-rules.mk endif At least the VDR solution means that if I just care about fixing the package in normal Debian mode, I can look at Debian rules and see what's going on, not have to go look at some other file which contains the real debian/rules. This is all far nicer than (for example) the packaging for the kernel, which is really scary, but does have the right shbang line. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: debian/rules make -f restriction
Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? It is not an overridable error, and I haven't seen any reason yet to convince me to make it one. You do have some reasons, but none I have seen that would not be simple to do in make directly as well. As long as you have those packages wherever, feel free to do what you want. Those you (want to) upload into Debian do need to follow policy. -- bye, Joerg Some NM: main contains software that compiles with DFSG. [hehehe, nice typo] Of course, eye mean complies, knot compiles. Sum typos cant bee caught bye spelling checkers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On 2009-10-29, Joerg Jaspert jo...@debian.org wrote: It is not an overridable error, and I haven't seen any reason yet to convince me to make it one. You do have some reasons, but none I have seen that would not be simple to do in make directly as well. As long as you have those packages wherever, feel free to do what you want. Those you (want to) upload into Debian do need to follow policy. Looks like policy is in need of changing here. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, Oct 29 2009, Philipp Kern wrote: On 2009-10-29, Joerg Jaspert jo...@debian.org wrote: It is not an overridable error, and I haven't seen any reason yet to convince me to make it one. You do have some reasons, but none I have seen that would not be simple to do in make directly as well. As long as you have those packages wherever, feel free to do what you want. Those you (want to) upload into Debian do need to follow policy. Looks like policy is in need of changing here. Given that this policy rule i massively followed (all but one set of packages from a single maintainer), that while there are a lot of elegant languages and different ways to build packages, and we had to chose one (I do not want to see ./debian/rules written in, say, shoop or algo, or the ultimately elegant smalltalk), I see no reason yet to change well established and uniformly followed policy. People might prefer to do things differently (I, and dh proponents, might think perl might be a great ./debian/rules interpreter), but ultimately this does not really come down to personal preference. Policy is a standards document, and changing this widely followed rule is going to take some compelling reason. manoj -- Recent investments will yield a slight profit. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On 2009-10-29, Manoj Srivastava sriva...@debian.org wrote: On Thu, Oct 29 2009, Philipp Kern wrote: On 2009-10-29, Joerg Jaspert jo...@debian.org wrote: It is not an overridable error, and I haven't seen any reason yet to convince me to make it one. You do have some reasons, but none I have seen that would not be simple to do in make directly as well. As long as you have those packages wherever, feel free to do what you want. Those you (want to) upload into Debian do need to follow policy. Looks like policy is in need of changing here. Given that this policy rule i massively followed (all but one set of packages from a single maintainer), that while there are a lot of elegant languages and different ways to build packages, and we had to chose one (I do not want to see ./debian/rules written in, say, shoop or algo, or the ultimately elegant smalltalk), I see no reason yet to change well established and uniformly followed policy. I didn't say that, right? Please don't lay words into my mouth. I said here to specify the concrete case of policy describing the first n bytes of debian/rules despite the interface being completely in accordance with the normal procedures (i.e. being a Makefile and even make -f compliant). Lintian's executable-not-elf-or-script speaks about scripts in general but I don't see anything at first glance that specifies the first 3 bytes of executables that are not scripts in the policy neither. Regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Philipp Kern wrote: I didn't say that, right? Please don't lay words into my mouth. I said here to specify the concrete case of policy describing the first n bytes of debian/rules despite the interface being completely in accordance with the normal procedures (i.e. being a Makefile and even make -f compliant). Personally I think debian/rules shouldn't be restriked to make. But I know, that changing this has an rather heavy impact, so this is something completely different from our current problem. But like Philipp, Lucas or Charles I believe, that the policy is too specific in requiring a fixed shebang line, instead of just stating, that debian/rules must be a Makefile which should execute itself when ran as a binary. But obviously I'm representing a tiny corner case here, which nobody really cares about, so I don't expect to get any reasonable support in changing the policy. And as it seems, just silently overriding and ignoring this error isn't an option either. So the only options we have left are, to make a probably hard to maintain debian/rules (if it is possible at all - believe me, it's not that easy as it seams), find an external solution or simply take away this feature. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, Oct 29 2009, Tobi wrote: But like Philipp, Lucas or Charles I believe, that the policy is too specific in requiring a fixed shebang line, instead of just stating, that debian/rules must be a Makefile which should execute itself when ran as a binary. What no one has addressed is the wildly different behaviour that this rules file has when addressed as ./debian/rules and make -f debian/rules when one has the the Magic variables set. If I ahve the magic variables set, and call it as % make -f ./debian/rules, I get the standard behaviour. If I turn around and call it as % ./debian/rules, I get totally different behaviour. This is confusing. This is slick, and obfuscatory. By itself it would qualify as a bug in my eyes. What happens if we run the makefile through the shell script with the variable set, but don't execute the filtered Makefile, but save it? We now have two makefiles, one the normal one, the second one which has been filtered through the shell script, but no more on-the-fly mangling of a Makefile through a shell script that does obscure things to the Makefile on the fly. Actually, the on the run mangling of the makefile is cute, but harder to debug. I do not see it as elegant, but has a clever hack that makes things harder to read, really. manoj -- If pregnancy were a book they would cut the last two chapters. Nora Ephron, Heartburn Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, 2009-10-29 at 15:54 +, Matthew Johnson wrote: On Thu Oct 29 15:58, Michael Banck wrote: On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? As long as you don't have an objection against having serious bugs filed and your packages not be part of a stable Debian release, I guess not. put me in the camp that doesn't think this is necessary. If it behaves precisely the same way as a makefile which does have that shbang line when compiling the standard Debian package I really don't think there is a problem with this. I'm also against the suggestion which reduces debian/rules to: ifeq () include real-debian-rules.mk else include alternate-debian-rules.mk endif At least the VDR solution means that if I just care about fixing the package in normal Debian mode, I can look at Debian rules and see what's going on, not have to go look at some other file which contains the real debian/rules. Not true. If you were not familiar with the special script, you would have to read that entire script to understand what it does. OTOH, in the make-only approach it is easier to discard the contents of alternate-debian-rules.mk entirely (since that special variable is, well, special). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Manoj Srivastava wrote: If I ahve the magic variables set, and call it as % make -f ./debian/rules, I get the standard behaviour. If I turn around and call it as % ./debian/rules, I get totally different behaviour. True but if you DON'T set the magic variable, you get the exact same behaviour, whether you call make -f ./debian/rules or ./debian/rules. And IMHO that's all that should be strictly required. I don't expect anyone to accidently set a variable SPECIAL_VDR_SUFFIX. And whoever sets this variable does this for a reason and will surly not call make -f ./debian/rules. Besides this, it's well documented. This is confusing. This is slick, and obfuscatory. By itself it would qualify as a bug in my eyes. Talking about obfuscated debian/rules... there's much, much worse out there! I consider this, to be a friendly debian/rules: http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr-plugin-epgsearch/trunk/debian/rules ...if you know cdbs and you might need to look up /usr/share/vdr-dev/dependencies.sh. But the shebang simply is nothing to worry about. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Thu, Oct 29, 2009 at 03:54:23PM +, Matthew Johnson wrote: On Thu Oct 29 15:58, Michael Banck wrote: On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: Are there any serious objections against just overriding and ignoring the Linitan warning about not having make -f in the shebang line? As long as you don't have an objection against having serious bugs filed and your packages not be part of a stable Debian release, I guess not. put me in the camp that doesn't think this is necessary. If it behaves precisely the same way as a makefile which does have that shbang line when compiling the standard Debian package I really don't think there is a problem with this. I agree, Policy seems to be overly specific here; it should concern itself with *interfaces*, not with the internal details. I don't think the fact that someone can find examples where ./debian/rules vs. make -f debian/rules will behave differently is a justification for this level of constraint in Policy, when those examples are corner cases that have nothing to do with how we build packages. That said, I think it's entirely inappropriate for individual maintainers to cook up clever debian/rules that violate Policy as written. Policy is the repository of our shared consensus for how packages must work, and maintainers should not presume to ignore Policy just because they think it's wrong. Debian Policy embodies 15 years of accumulated experience; and while it still has bugs (and presumably always will), the way to deal with those bugs is to resolve them through the public policy process, not to be a cowboy and upload non-compliant packages because you think you know better than Policy. And, until Policy /is/ amended to say vdr's usage is ok, we should continue to treat this behavior of vdr packages as a Policy violation of the appropriate severity. Which I don't agree is OMG critical block it from the archive, I think vdr should be allowed to use a lintian override for this error. (Other packages that hit this lintian error are probably buggy under any reasonable formulation of the Policy requirement, and should therefore be regarded as broken and kept out of the archive regardless - but it would be non-trivial for lintian's static checking to distinguish vdr from those other packages...) On Thu, Oct 29, 2009 at 07:26:42PM -0300, Felipe Sateler wrote: On Thu Oct 29 15:58, Michael Banck wrote: I'm also against the suggestion which reduces debian/rules to: ifeq () include real-debian-rules.mk else include alternate-debian-rules.mk endif At least the VDR solution means that if I just care about fixing the package in normal Debian mode, I can look at Debian rules and see what's going on, not have to go look at some other file which contains the real debian/rules. Not true. If you were not familiar with the special script, you would have to read that entire script to understand what it does. OTOH, in the make-only approach it is easier to discard the contents of alternate-debian-rules.mk entirely (since that special variable is, well, special). We have plenty of packages in the archive that have this problem while being perfectly compliant with Policy's shebang requirement. I don't see any point in trying to use the specter of obfuscated code to justify this requirement. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: debian/rules make -f restriction
On Thu, 2009-10-29 at 17:58 -0700, Steve Langasek wrote: Not true. If you were not familiar with the special script, you would have to read that entire script to understand what it does. OTOH, in the make-only approach it is easier to discard the contents of alternate-debian-rules.mk entirely (since that special variable is, well, special). We have plenty of packages in the archive that have this problem while being perfectly compliant with Policy's shebang requirement. I don't see any point in trying to use the specter of obfuscated code to justify this requirement. I believe the point of said policy requirement is precisely that. Whether you can obfuscate in other ways is irrelevant. As you said, if the requirement is not needed, then it should be removed (I don't have a strong opinion on that). But the point that was being raised was that it was easier to read, and I pointed out where it wasn't true. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, 2009-10-28 at 16:02 +0100, Tobi wrote: [1]: http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh asks for a password. also nothing in what you said explains why you can't do what you want using a makefile. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Julien Cristau schrieb: asks for a password. Sorry, wrong link: http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr/trunk/debian/make-special-vdr.sh also nothing in what you said explains why you can't do what you want using a makefile. Because make-special-vdr.sh needs to modify debian/rules itself. This way debian/rules doesn't get contaminated with stuff that goes beyond the scope of building the regular Debian package -e except for the shebang line. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, Oct 28 2009, Tobi wrote: Hello! Debian Policy 4.9 says about debian/rules: 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. In the VDR and VDR plugin packages, we use something like this: /bin/sh debian/make-special-vdr.sh make-special-vdr.sh [1] normally simply does a '/usr/bin/make -f $@'. But when a special environment variable is set, it modifies the source package to build binaries with a different name. I am pretty sure this can easily be done in a make file, and I suspect it is fairly trivial to do so. The reason for this is, that this allows us to build VDR and VDR plugin packages for the current development version of VDR, which can be installed side-by-side to the normal VDR packages, allowing the development version to be easily tested without needing to replace the stable VDR packages. I do not see why this needs a indirection using a shell script. This makes it easier for users to take a peek at newer VDR versions, before they become stable and will be released in Debian, which we believe is good, because it helps to improve the code quality. Can you show us a technical reason why this can't be done using a makefile? This smacks much more of a personal preference than a technical need. Until now, we silently ignored the Lintian warning about this possible policy violation, because the condition so that it can be invoked by saying its name rather than invoking make explicitly. still is true. And it still can be built by invoking make explicitly. Manoj Srivastava now filed some (automatic) bug reports about this, so I'm seeking advice on what to do. They were all manually filed, with checks. Should the policy be changed to something like: It must be able to be invoked by saying its name or by invoking make explicitly. This can usually be done by using #!/usr/bin/make -f as the shebang line. Or should we just add a Linitan override? Or do we really need to use #!/usr/bin/make -f as the shebang line in debian/rules? Personally I would vote for dropping the make requirement from the policy all together. I might be mistaken, but I think none of the build tools calls make explicitly with debian/rules. A debian/rules might even be a Python or Rake script. There are a number of features that one may rely on if ./debian/rules is a Makefile. It has a uniform calling convention, you can specify -n, -d, -p, and -t and get consistent results, you may pass options using MAKEFLAGS, other Maekfiles may include debian/rules for debugging and statistical purposes (Yes, I have done that). There is also a clear way of passing in variable values, and overriding internal variables on the command line. Finally, most of the source packages already conform to this policy rule, with the vdr packages being the major standouts. To change policy, especially one which the project mostly complies with, you must come up with a more compelling reason than We like doing things our way. [1]: http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh This seems to want a user name and password. manoj -- Every journalist has a novel in him, which is an excellent place for it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, Oct 28 2009, Tobi wrote: Julien Cristau schrieb: asks for a password. Sorry, wrong link: http://svn.debian.org/wsvn/pkg-vdr-dvb/vdr/vdr/trunk/debian/make-special-vdr.sh also nothing in what you said explains why you can't do what you want using a makefile. Because make-special-vdr.sh needs to modify debian/rules itself. This way debian/rules doesn't get contaminated with stuff that goes beyond the scope of building the regular Debian package -e except for the shebang line. This is what the make directive 'include' is all about. Conditionally, include fileA or fileB. Each file is all uncontaminated now. This is not a technical shortcoming of using Makefiles. manoj -- The reason why worry kills more people than work is that more people worry than work. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: debian/rules make -f restriction
Because make-special-vdr.sh needs to modify debian/rules itself. This way debian/rules doesn't get contaminated with stuff that goes beyond the scope of building the regular Debian package -e except for the shebang line. Why not so it the other way round, i.e. start two different scripts (or the same script with different parameters) from a debian/rules Makefile depending on the environment variable? -- Dipl.-Phys. Fabian Greffrath Ruhr-Universität Bochum Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT) Universitätsstr. 150, IB 3/134 D-44780 Bochum Telefon: +49 (0)234 / 32-26334 Fax: +49 (0)234 / 32-14227 E-Mail: greffr...@leat.ruhr-uni-bochum.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Tobi wrote: Or should we just add a Linitan override? Or do we really need to use #!/usr/bin/make -f as the shebang line in debian/rules? Use make. it is able to do all the things you're doing right now, including to do different stuff based on an environment setting. Personally I would vote for dropping the make requirement from the policy all together. I might be mistaken, but I think none of the build tools calls make explicitly with debian/rules. A debian/rules might even be a Python or Rake script. Oh god, no. And I'm not even going to explain why.Think about it. Tobias [1]: http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Personally I would vote for dropping the make requirement from the policy all together. I might be mistaken, but I think none of the build tools calls make explicitly with debian/rules. A debian/rules might even be a Python or Rake script. [Bernd Zeimetz] Oh god, no. And I'm not even going to explain why.Think about it. That's a very unhelpful response. If that's all you had to say, why even bother to reply? Was it just so you could sound smart, or make Tobias sound dumb? At least he bothered to explain his reasoning. See Manoj's mail for a perfect example of explaining (a) why they don't need the hack, and (b) why it is useful to require 'make'. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Fabian Greffrath wrote: Why not so it the other way round, i.e. start two different scripts (or the same script with different parameters) from a debian/rules Makefile depending on the environment variable? Might be possible, but it would require major changes to debian/rules, but our goal is to keep debian/rules as simple as possible without any stuff you wouldn't expect in a Debian package. Before adding any ugly stuff to debian/rules I would rather let an external build script to the dirty work. That's just harder to integrate into our pbuilder build process. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Manoj Srivastava wrote: This is what the make directive 'include' is all about. Conditionally, include fileA or fileB. Each file is all uncontaminated now. This is not a technical shortcoming of using Makefiles. You're right. What we do might be possible from within the Makefile itself. Maybe even a custom cdbs rule might be possible. But it's not that easy and it would make the debian/rules less readable. The solution we have right now is in some way elegant, because you have only to deal with a standard debian/rules and besides the different shebang line there's nothing else to care about. But putting the technical aspect completeley aside - with our hack, the debian/rules still bahaves as it should be. You can run debian/rules and you can run make -f debian/rules. It's still a self executing Makefile. IMHO the policy is a little bit over-specific, when stating It must start with the line #!/usr/bin/make -f. It seems nobody else has ever thought about changing the shebang line of debian/rules, so most likely the policy will not get changed just because I stumbled upon this issue. So what about just adding a Linitan override and leave everything else as it is? Our debian/rules still follows the spirit of the Debian policy, even if it does not start with #!/usr/bin/make -f. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
Le Wed, Oct 28, 2009 at 04:02:32PM +0100, Tobi a écrit : Debian Policy 4.9 says about debian/rules: 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. Dear all, I also do not understand that rule. There are a larger number of packages that are simply removing all the content from the make file, for instance like: #!/usr/bin/make -f %: dh $@ or #!/usr/bin/make -f include /usr/share/R/debian/r-cran.mk or any other variation on the theme. I think that the key part of the Policy is the interface: debian/rules can be called with arguments such as ‘build’, ‘clean’, etc. When unique features of GNU Make are not needed, I do not see much advantage in requiring that the parts that actually do the work are wrapped into a makefile. Can’t we just trust the maintainers instead of putting restrictions that in the end are only increasing complexity for no benefit? You know, this ‘Do-O-cracy’ stuff that is supposed to make Debian different and is progrssively becoming a ‘Do-what-I-say’ with increasing archive restrictions and penury of DDs caused by a too long recruitment process. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, Oct 28 2009, Tobi wrote: Fabian Greffrath wrote: Why not so it the other way round, i.e. start two different scripts (or the same script with different parameters) from a debian/rules Makefile depending on the environment variable? Might be possible, but it would require major changes to debian/rules, but our goal is to keep debian/rules as simple as possible without any stuff you wouldn't expect in a Debian package. It requires almost no changes to the rules file. Before adding any ugly stuff to debian/rules I would rather let an external build script to the dirty work. That's just harder to integrate into our pbuilder build process. It is not at all harder to include it into pbuilder. manoj -- Houdini escaping from New Jersey! Film at eleven. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, Oct 28 2009, Tobi wrote: Manoj Srivastava wrote: This is what the make directive 'include' is all about. Conditionally, include fileA or fileB. Each file is all uncontaminated now. This is not a technical shortcoming of using Makefiles. You're right. What we do might be possible from within the Makefile itself. Maybe even a custom cdbs rule might be possible. But it's not that easy and it would make the debian/rules less readable. I beg to differ. It is really trivial, and it does not make the rules file less readable #!/usr/bin/make -f ifeq (,$(srip $(ENV_VAR_WE_LOOK_FOR))) include regular.mk else include special.mk endif Done. The solution we have right now is in some way elegant, because you have only to deal with a standard debian/rules and besides the different shebang line there's nothing else to care about. Actually, there is. My states makefile can no longer include debian/rules, because, you see, it is not a makefile. There are other ways that it does not look like a makefile, walk like a makefile, or quack like one. But putting the technical aspect completeley aside - with our hack, the debian/rules still bahaves as it should be. You can run debian/rules and you can run make -f debian/rules. It's still a self executing Makefile. That is just one aspect. IMHO the policy is a little bit over-specific, when stating It must start with the line #!/usr/bin/make -f. It is also a policy that everyone else seems to follow. It seems nobody else has ever thought about changing the shebang line of debian/rules, so most likely the policy will not get changed just because I stumbled upon this issue. We have thought of it, and rejected it as needless inconsistency. So what about just adding a Linitan override and leave everything else as it is? Our debian/rules still follows the spirit of the Debian policy, even if it does not start with #!/usr/bin/make -f. I do not think it follows the policy, no. manoj -- Karl's version of Parkinson's Law: Work expands to exceed the time allotted it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/rules make -f restriction
On Wed, Oct 28, 2009 at 07:05:30PM -0500, Manoj Srivastava wrote: On Wed, Oct 28 2009, Tobi wrote: Manoj Srivastava wrote: This is what the make directive 'include' is all about. Conditionally, include fileA or fileB. Each file is all uncontaminated now. This is not a technical shortcoming of using Makefiles. You're right. What we do might be possible from within the Makefile itself. Maybe even a custom cdbs rule might be possible. But it's not that easy and it would make the debian/rules less readable. I beg to differ. It is really trivial, and it does not make the rules file less readable #!/usr/bin/make -f ifeq (,$(srip $(ENV_VAR_WE_LOOK_FOR))) include regular.mk else include special.mk endif ummm, I don't think so. Have you actually looked at the packages? I'd suggest trying to provide a patch for one of them, because looking at this now it seems very non-trivial to fix...and this is from an outsider just like you, I've never even heard of these packages (just did a quick apt-get source and looked around). I don't see what the problem is...this really feels like bikeshedding to me. why not just let them do it their way? it's still a Makefile from every point that matters (just not head -1). Honestly this doesn't affect me so I don't care whether or not you let them do this, but I just think you shouldn't call it trivial, it (at least to me) clearly isn't, and your proposed solution doesn't provide the ellegance that their current one does. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
