Re: New maintainer's packaging - bewildering variety of information
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.
Reply to: