debian/rules "make -f" restriction
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. 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. 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. 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. 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. Tobias [1]: http://svn.opensourcefactory.com/svn/vdr/trunk/debian/make-special-vdr.sh -- 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
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
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 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
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
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
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
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
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: system users
Vincent Bernat wrote: > Here is the list of package that name the user with the name of the > source package: - vdr:vdr Tobias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian -- the best
> Let me express my appreciation and gratitude for Debian. Reading debian-devel during the last weeks, I had the same feeling that some positive counterpart to the recent discussions is needed to somehow keep the "balance". I intended to post the top 5 reasons, why I love Debian, but you were faster than me, so let me just add this to your thread: 1. From a users perspective, Debian just works! I recently installed and upgraded a lot of systems to Lenny without the slightest problem. My oldest system has been dist-upgraded from Woody to Etch to Sarge to Lenny - and it still works! 2. apt-get install 3. Debian is around for quite some time now, so we must be doing something right, mustn't we? 4. Debian has a pretty large community. And for a non-profit, volunteer-driven project, this works really well and it's fun to be part of it! 5. Debian values software freedom. It's nice to get tons of software for free and it's even nicer to have the freedom to take the ideas and knowhow expressed in this software to create something new. That's how it has always been in art and science. The world needs free software and it needs Debian :-) And as a bonus: 6. We have a world wide financial crisis and it's not Debian's fault :-) Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: building packages/ chroot/ pbuilder/...
Grammostola Rosea wrote: > How should I do it? I've seen a lot of different tools/ways on the > web... please give me some clear information and good references. Check out cowbuilder. The follwing references should get you going: http://wiki.debian.org/cowbuilder https://wiki.ubuntu.com/CowdancerHowto http://lkraider.eipper.com.br/blog/2007/10/cowbuilder-ccache.html I'm using cowbuilder to build packages for Etch, Lenny, Sid and Ubuntu Intrepid - works like a charme. Sometimes just cdebootstrap fails, you should then try debootstrap instead. Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: An ITP looks like forgotten
Am 11.05.2010 10:41, schrieb Cleto Martin Angelina: The bug #539568 is an ITP for a C++ sockets library. The ITP was created on Augus'09. I'm interested in this package too, and I wrote an email to the bug author and I've received that his email does not exists. In this cases, what should be done? I'm not the ITP author, but we've packaged this a while ago: http://svn.debian.org/viewsvn/pkg-vdr-dvb/general/libsockets/trunk/ dget http://e-tobi.net/vdr-experimental/pool-sid/source/base/libsockets_2.2.5-4.dsc It probably needs some polishing and an upstream-update. (CC-ing the ITP-Bug) Tobias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4be921ff.60...@e-tobi.net
