Some comments on the debhelper disadvantages: Manoj Srivastava writes: > Disadvantages: > i) One becomes dependent on them, and does not know what is going > on
try to run the helper programs with -v. You get a pretty good insight what's happening (although this may change, when Joey is switching the current sh implementation to perl). > ii) I, and a number of other people, find helper packages to be > less flexible than desired for complex packages; and a number > of people have left the helper package umbrella after gaining > some experience. (To be fair: lots of other people stick to > helper packages all through) True, although you can save much using the debhelper options -a and -i to act on all packages. > iii) Bugs in helper packages affect ones package, and one has little > control over the time for the fx (Joey has been wonderful so > far) Yes, I have to repeat this! > iv) On has to learn the helper package, and what the commands do, > this is akin to learning a restricted language (I porefer > sticking to Perl, C, C++, java, sh, etc, which are usefl > elsewhere as well what does dh_man do[if there is a dh_man]?) > v) packages using helper packages depend on the version of the > helper package installed on the machine they are built on. So > your package may be built broken on a machine with an old > helper package version (and not build on machines like my > machines, since I do not install helper packages at all) no, there's a dh_testversion program, that let's you insist on a specific version. Agreed, that you need this version, but that doesn't result in a broken package.
