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