Should we use cdbs? Why? Any exceptions? Did you used it before?
Gonéri Le Bouder
I tried to use CDBS on some packages from the SVN. Some months after for me the major issues are:
- Pro: Useful to keep package clean but only if the build process is very standard
- Con: no consensu in the team
- Con: difficulty for upload. Alexander is not a fan of CDBS
- Con: the great majority of games don't have a standard build system
- Con: misterious issues hard to understand
I agree with a "no cdbs" rule in the team. In this case i've to clean up ri-li and libenet.
Eddy Petrișor
I always admired the speed of package creation in Gentoo. The main reason behind the success and speed is the fact they use rules for classes of applications (gtk building rules, qt building rules, autotoolized building rules, etc.) and inheritance. This way they can reduce the amount of work needed per package if it can be included in a more generic class, which can happen most times, and they diverge only as much as needed. CDBS tries to do the same thing for debian packages. Thus I say we should give it a try for a couple of packages.
I never used cdbs before.
Miriam Ruiz
I've never used it. The problems I find with it are mainly:
- As many people are not familiar with it, requiring it for handling our packages can become an important entry barrier for joining the group.
- It's very difficult to know what the system actually does inside, as it handles everything automagically.
- I've tried to make minor changes, like adding -pg to CFLAGS, and was totally unable to find how to do it. If we decided to use it, we would probably need to make a fast course on it, or something like that.
- It makes it quite difficult to find sponsors for the packages.
I'd prefer to avoid its usage.
StefanPotyra
Used it once for a python module, but I neither like it very much, nor have I very good knowledge about it.
- Pro: Straight forward packages don't need much commands in debian/rules. Also it's a very powerful tool (see Eddy's description).
- Con: It imho contains much black magic. It deludes that you don't need to know about its internals since it does good work for simple packages OOTB. But once you need to add some non straight forward customization to a package, you need quite good understanding of cdbs internals to get it right.
Linas Žvirblis
No. Tools that try to be smarter than a user are evil by design. Not that I know. Not enough to comment much.
ReinhardTartler
It promises to make packaging really easy. In fact, if you don't need much customisation and the package is really straight forward to use. However, it gets more difficult if the upstream build system doesn't catch all your needs, and you have to use the hooks cdbs provides. And to learn them is a hard job, since the cdbs documentation is very sparse and inconsistent on this point. Debugging make rules isn't something many people are familiar with. Therefore I'd also suggest to avoid it.
Alexander Schmehl
I tried to use it before; while I agree, that it makes it quite easy for maintainers to create packages, I think it goes to far, because it's just not as easy to see what it actually does. See... if we use debhelper, we habe small in the debian/rules. They tell me what they do just by their name. With cdbs I just see some includes, and need to dig deeper to see, what those includes will result into.
PS: That I don't like it, is not a reason to drop it for the team; I just one member of the team.
Jon Dowland
Never used it. If we need to manage patches, then I think using a system is better than doing things manually (look at the php4 package, which I find very difficult to use, for an example). I've heard bad things about cdbs, fewer bad things about dpatch, and good things about quilt. But I have no experience of all three.
Sam Hocevar
No. Some game packages I maintain are sometimes so complicated that without upstream collaboration there is no way to use CDBS properly. I won’t strongly object other people using it, but I won’t use it.
Simon Ruggier
I like CDBS, because it saves the packager time spent reinventing the wheel for things like debug packages, autotools config.* file updating, and other usages of standard build systems. Also, there are a certain bunch of debhelper calls that are basically taken for granted and used in every package, and CDBS factors that out of the rules file. That makes it easier to review, because every line that remains is there to deal with issues that are specific to the package being built.
The learning curve can be helped by the manual, installed at file:///usr/share/doc/cdbs/cdbs-doc.html, or online at http://perso.duckcorp.org/duck/cdbs-doc/cdbs-doc.xhtml. Members of the games mailing list could also help if anyone gets stuck on something.
Paul Wise
I believe CDBS should be depreciated in favour of debhelper 7.