Coin, Steve Langasek <vorlon@debian.org> writes: > and replace it with a very small shell script. For cdbs, you delete one > line and have to replace it with your reimplementation of a very large > makefile... That's obvious because CDBS does not target at doing little independent tasks (even if some may be *perhaps* be transformed to dh_*), but to autogenerate rules. CDBS is a layer over debhelper, this cannot be simply compared this way. > Oh, I disagree; I think I have a pretty good idea what the benefits are of > CDBS, I just think that many CDBS proponents underemphasize the *downside* > of CDBS. That's not true for everybody. The auto control generation is now never run automatically because we agreed it could cause harm. > So tell me, how do you know a priori whether the software you're packaging > is going to be "common", or if it's going to need to deviate from CDBS at > some point in the future? If you're recommending a packaging style to a new > packager who probably doesn't have the level of committment to learn more > than a single helper style, how do you know whether they will at some point > need to package something that doesn't fit in cdbs's neat little view of the > world? You simply don't care about this... If something is missing or inadéquate you juste hook on makefile rules and add your own commands (debhelper if necessary). you can even stop including some classes and reimplement what is uncommon and thus has no reason to be in a class. I never found any package being fully uncommon, so i see no reason not to use CDBS if you feel well with this tool with any package.. If the packager has no time to learn Debian tools correctly, then he must not be sent to NM, or must not be accepted by AM or DAM, that's really obvious. People willing to have a @debian.org email for fun or unwilling to learn and work seriously can just can become MOTUs... What would you say if i told you i had not yet time to learn how the BTS work because my level of committment is not high enough and that i won't be able to manage my bugs until 6 more months ? Sometimes i really don't understand you... > I was pointing out that you can't learn anything about what cdbs does by > looking at the debian/rules of a package that uses it. If I have a > debian/rules file that invokes a command, and I don't understand what that > command does, I can look at the manpage. If I have a debian/rules file that > includes other makefiles, my choices are to look at the include file itself > and study it (for which the *shortest* of these is as long as the stock > dh-make template rules file), or track down the cdbs documentation... which > in at least one noteworthy case tells me to go look at the include files > anyway (hee). This was true and is less and less true. This case is in an unfinished part (debhelper parameters), and i don't recall any other case. I'm not sure in the youth of debhelper manpages were initially perfectly exhaustive. This is very common in FOSS projects to have lacks of documentation, CDBS is no exception. The documentation is still work in progress and is actively improved over time, just be patient *or* help. > The flip side of this is that the behavior of cdbs-using packages is always > changing, without the knowledge or control of the package maintainer. E.g., > while I was drafting this message, > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372273;msg=10> showed up > in my mailbox... In the past some mistakes were done in debhelper too, even if i don't recall a specific case to mention. That's not often this happen to CDBS, but i agree this should be avoided, that's why i'd like Peter to finaly accept co-maintainership. > No, clearly makefile includes shouldn't have manpages; but some kind of > documentation that tells cdbs users what they should or shouldn't be able to > depend on would be a good idea. In the absence of such documentation I > think the current answer to what they can depend on is actually "very > little", which is a big part of why I don't encourage its use. A documentation do exist, even if you seem to be completely blind and features which are described are behaviors you can count on. When a feature has changed for very important reasons like the control auto generation one, a warning is displayed (so you know you cannot count on it). Undocumented parts are either documentation lack or internal stuff you should not care about and count on. Nevertheless, i do agree this needs improvements (please reply to the part of the thread with bubule if you want to continue on this specific topic). -- Marc Dequènes (Duck)
Attachment:
pgplwmAA7xnFf.pgp
Description: PGP signature