Re: Opinions on CDBS amongst sponsors
On Wed, 2006-12-13 at 10:29 +0200, Jari Aalto wrote: Especially adding the EXAMPLES sections would greatly improve all the manual pages by listing the typical usage cases. Here is an exerpt. Patches are probably most welcome ;) Thijs signature.asc Description: This is a digitally signed message part
Re: Opinions on CDBS amongst sponsors
Russ Allbery [EMAIL PROTECTED] writes:
Neil Williams [EMAIL PROTECTED] writes:
So the main objections to CDBS are that it hides too much, making it
hard to know what is actually going on.
How does this compare with other helper scripts like debuild and
pdebuild?
Those aren't used as part of the package build process; they're wrappers
around it that one doesn't have to use even if the maintainer does. I
think you mean debhelper. debhelper, unlike CDBS, has actual
documentation: every command has a man page, and every command does what
the man page says it does.
There would be lot to improve in packaging manual pages because they
stack over the lower level commands making it hard to understand
what exact options {are|can be use used}.
Especially adding the EXAMPLES sections would greatly improve all the
manual pages by listing the typical usage cases. Here is an exerpt.
Includes EXAMPLES section
---
debuild yes
dpkgyes
dpkg-buildpackage no
dpkg-debno
dpkg-query no
dh_make no
lintian no
fakerootno
make-kpkg no
pdebuildno
pbuilderno
cowbuilder no
It's no surprise if understanding the packaging system is difficult,
no matter if it were debhelper.
Jari
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? Badly-documented black-box on something that we have to understand well to sponsor or work with. This is Not Acceptable IMO. Which kinds of packages have the most trouble with a CDBS method? Any. I do not sponsor anything CDBS, nor would I co-maintain CDBS packages. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
* Neil Williams ([EMAIL PROTECTED]) [061211 11:26]: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. I don't use automatic debian/control management and I personally wouldn't recommend using that part of CDBS. What are the problems with CDBS (apart from debian/control automation)? I need to reverse-engineer code every time I use it There was a good blog entry recently about automation: Good helpers make the tasks easier by reducing complexity. cdbs doesn't do that - it surely makes the task easier for people used to it, but for all others, it is a big black box adding complexity. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
Neil Williams wrote: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. jftr: i do sponsor cdbs packages, but i can't give any tips to the sponsoree in case there are problem whith it. What are the problems with CDBS (apart from debian/control automation)? For me, it's all about calling the dh_* scripts: cdbs always calls all every available dh_* it seems, whereas handcrafted rules do only call the required ones. Beeing adicted to simplicity, this is not a cleverness feauture to me, that's raw force. Some time ago, when squashfs and unionfs were both building their binary-modules packages on their own, unionfs took about 30 seconds to build with handcrafted rules for all i386 flavours, whereas squashfs took over 2.5 minutes with cdbs (and build: for squashfs takes less time than the one of unionfs). The effect of calling all dh_* was cumulating, though. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On 2006-12-11, Neil Williams [EMAIL PROTECTED] wrote: What are the problems with CDBS (apart from debian/control automation)? The biggest problem are the layers of obscurity added by cdbs and the fact that the best docs are diving into the source. (and the fact that there has been some cdbs revisions that had broken other packages because changes wasn't 100% well thought) People have told me that until you have read and understood the cdbs classes you use, you should not use cdbs. I do not disagree much on that. As new package maintainer, you need to know what happens and shouldn't use cdbs to hide what is really going on. CDBS does also have its advantages somewhere - the use of a common system for larger stuff instead of all people inventing their own different build-abstraction-layer. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
Hi, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? my biggest problem about CDBS is the obscurity it adds to packages. Example: You are a new-time debian developer. You want to adopt a package that is already in Debian using cdbs. Now you have a debian/rules files with some includes and some unclearly further rules. To find out what actually happens when building is done, you will have to have worked a lot with CDBS to understand what actually happens, when building or you need to tackle with the include files to find it out. This is not to hypothetical though. I was in interest several month ago to adopt a package which used CDBS and was poorly maintained. In fact i did resign to that, because it was to obscure for me and that time i wasn't too interested to figure out how to change it. Best Regards Patrick signature.asc Description: OpenPGP digital signature
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 11:38:41 +0100 Andreas Barth [EMAIL PROTECTED] wrote: * Neil Williams ([EMAIL PROTECTED]) [061211 11:26]: Yet some sponsors have made it clear that CDBS is not their preferred method and are somewhat unwilling to sponsor CDBS. I don't use automatic debian/control management and I personally wouldn't recommend using that part of CDBS. What are the problems with CDBS (apart from debian/control automation)? I need to reverse-engineer code every time I use it There was a good blog entry recently about automation: Good helpers make the tasks easier by reducing complexity. cdbs doesn't do that - it surely makes the task easier for people used to it, but for all others, it is a big black box adding complexity. Fully agreed. Factorising rules is alright, would be unreasonable to have to write every single command each time, but factorising to the extreme, like CDBS does, making the building system utterly complex is a bit absurd too. -- Ricardo Mones ~ Datei nicht gefunden Fehler 404 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Monday 11 December 2006 11:25, Neil Williams wrote: What are the problems with CDBS (apart from debian/control automation)? Generally I am not a fan of layers of abstraction once the abstraction is too abstract. Frameworks are great as long as they do what you expect. But if they fail to do what you expect you are boned. Frameworks may even be buggy which means you totally depend on the person who created the framework. CDBS for me means: - documented mainly by its source (that - since it's just makefiles - looks even worth than some of my early Perl projects) - brute-force approach by calling everything that starts with dh_ - not simple any more once you try to do non-standard things Some package maintainers may think the default debian/rules file created by dh-make is uncomfortable. And I admit that using debhelper makes writing the same prayer into debian/rules time and again. But at least I understand which steps are done when calling the different stages of debian/install manually. And sometimes I even dear that package maintainers using CDBS don't even care about what happens exactly. IMHO debhelper (dh_*) is the right abstraction layer. I already looked at packages where everything was done using basic shell commands. That's not very clear to the reader either and too low-level for common use. When sponsoring packages I claim to understand how the package is built to spot major mistakes. With CDBS I can just insert a coin and hope for the best. It just leaves me with a let's hope this one builds on the buildds, too. Kindly Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Monday 11 December 2006 12:05, schönfeld / in-medias-res.com wrote: This is not to hypothetical though. I was in interest several month ago to adopt a package which used CDBS and was poorly maintained. In fact i did resign to that, because it was to obscure for me and that time i wasn't too interested to figure out how to change it. Well, to me it's just a matter of personal taste.. You could argue the other way roumd: what I do like in cdbs is that you focus on your rules on the specific difference that your package needs from a common build system. That is to say that you don't have to read and parse a complicated rules files until you get why this or that trick happen... The three criticisms I could say to cdbs is : - Lack of documentation, even though duck's page is very usefull there, but does not cover all cases - Put a strong responsability on cdbs maintainers. If cdbs would to be broken at some point, then the more package using cdbs there would be, the more broken package we would get - Some difficulties for teaching package practicies. I'll let you do it the full way and then teach you a way to circomvent everything in two line... Apart from that I am really happy using it. Romain
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 10:25:58 + Neil Williams [EMAIL PROTECTED] wrote: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? I'm asking this because it is directly relevant to my emdebian work : I'm writing wrappers and helpers that take the drudgery out of converting packages for cross-building. Part of that is writing a replacement for debuild that can cope with cross-building, handling cross-built dependencies and cross-building packages such that there is no effect on building native packages on the same system. It's a question of extent. How much abstraction is too much, how much control is too little? Documentation is going to be a key point. I'm trying to write the scripts to have multiple levels of verbosity so that with foo -v -v -v it gives you output that is almost step-by-step walking you through the commands being used. I'm also preparing manpages for each command - something that cdbs lacks (which should probably be a bug report). I'll also be updating the emdebian wiki to keep those docs in sync too. Cross-building is another learning curve beyond Debian packaging and I'm conscious that it isn't easy to explain or follow sometimes. If anyone is interested in helping proof-read the documentation and script output from a position of someone new to cross-building, let me know. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpb1zGXgzvFQ.pgp Description: PGP signature
Re: Opinions on CDBS amongst sponsors
Neil Williams wrote: Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? I have seen bugs that could have lead to FTBFS, due to the fact that people mixed up their build-depends and build-depends-indep because they didn't notice that CDBS was calling an external program in the clean target. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
Neil Williams [EMAIL PROTECTED] writes: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. Have there been *actual* incidences when a CDBS package has failed on the buildd's for reasons that can be clearly attributed to CDBS itself? Yes. For example, a bug in CDBS (since fixed, I believe) broke dependency handling between libraries built from the same source package unless one ordered the binary packages in debian/control just right. Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? You're really comparing apples to kumquats here; CDBS and debuild are completely unrelated. You can use either debuild or dpkg-buildpackage to build CDBS-using packages, for instance. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, Dec 11, 2006 at 10:58:27AM -0800, Russ Allbery wrote: Neil Williams [EMAIL PROTECTED] writes: How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. The other thing with these other tools is that they tend to do a single, linear task without a great deal of policy or other decision making that affects the built package. It shouldn't make much diference if they are used or not. CDBS, on the other hand, has a very substantial effect on the built package. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Opinions on CDBS amongst sponsors
On Mon, 11 Dec 2006 10:58:27 -0800 Russ Allbery [EMAIL PROTECTED] wrote: Neil Williams [EMAIL PROTECTED] writes: So the main objections to CDBS are that it hides too much, making it hard to know what is actually going on. How does this compare with other helper scripts like debuild and pdebuild? Those aren't used as part of the package build process; they're wrappers around it that one doesn't have to use even if the maintainer does. I think you mean debhelper. debhelper, unlike CDBS, has actual documentation: every command has a man page, and every command does what the man page says it does. OK, I see that. In which case, my own wrappers are also unlike CDBS and much more like debhelper. The commands executed by the scripts can be performed manually and I'm being careful to ensure useful documentation. As you say, every command with a man page, every man page checked for accuracy before each release. (Take a look at apt-cross - v0.0.5 just uploaded to Debian.) Do those who dislike CDBS also all use dpkg-buildpackage in full or is debuild better somehow? You're really comparing apples to kumquats here; CDBS and debuild are completely unrelated. You can use either debuild or dpkg-buildpackage to build CDBS-using packages, for instance. True, but debuild is much closer to what I'm actually doing for emdebian. It just so happens that the scripts also have to be able to cope with CDBS packages, hence the comparison. I'm primarily interested in sponsoring embedded packages (or packages small enough to be useful on embedded devices) and although I use CDBS for my own packages, I have no particular preference for packages that I may sponsor. Thanks for the feedback on CDBS one and all - very helpful. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpeOR3C4ONhq.pgp Description: PGP signature
