Re: New maintainer's packaging - bewildering variety of information
Hi,
I am biased about this, so my rationale might not be the best
thing to look for. But the bottom line is that you should do what is
right for you, and the majority of people start out by using
debhelper or equivalent.
Helper Package (debhelper) Advantages
i) These make it easier for novices to package things. There si
knowledge built into the scripts, and it may be easier to let
the helper package do the arcane tasks
ii) If mainatined, they keep fairly good track of policy, and
changes to policy may be handled merely by upgrading the helper
package and rebuilding one package
Disadvantages:
i) One becomes dependent on them, and does not know what is going
on
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)
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)
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)
Doing ones own rules:
Advantages:
i) It is easier to get things right, since one does not have to
consider all possible packages all the time
ii) One can exercise precise control, and can be more flexible
iii) One gets to know Debian policy rather well
iv) one can clone rules files and get most of the benefits of the
helper packages over time (my rules files are highly
standardized, really, with about 3-4 templates to choose from)
v) It is more satisfying for some people, like me
Disadvantages:
i) You have to know exactly what to do (this is not as bad as it
appears, since that is how we all did it before debmake)
ii) You have to keep track of policy, and change all your rules
files when policy changes
iii) More prone to making errors (human error) than a script is
I, in my inimitably biased fashion, prefer to think my rules
as hand crafting package, rather than a cookie cutter approach ;-)
>>"Jules" == Jules Bean <jmlb2@hermes.cam.ac.uk> writes:
Jules> There's debstd, but I see that's deprecated.
Yep, and no longer maintained and kept up with policy (one of
the reasons why I do not use helper packages -- lord only knows when
the maintainer shall lose interest, and make my packages unworkable)
Jules> There's debhelper, which is being currently updated, and I see
Jules> quite a few packages which use it.
Yep. Thats the current helper package.
Jules> And then there's the school of thought (Manoj's I think, but
Jules> that may be slander) that you should do it yourself.
http://www.master.com/%7Esrivasta/ has a set of rules files
which a number of people have found useful.
Jules> And there's manoj's own cvs-buildpackage which appears to be
Jules> orthogonal to the above.
cvs-buildpackage has nothing to do with helper packages. This
is a utility that allows you to put packages (which may or may not
use debhelper, debstd, etc) under CVS. If you like CVS, and like
having the ability to roll back changes, to keep a branch for hamm
while the latest is on the main trunk, and upstream changes go on the
vendor branch (and all the other benefits of revision control
systems), check out cvs-buildpackage.
You can still use debhelper et all. cvs-buildpackage takes an
already packaged package, and helps you put it in CVS.
As jules says, this is orthogonal.
Jules> There's the devscripts package, which includes dch, build and release.
I do not use these; dpkg-buildpackage should serve the same
purpose as build, I think, and dupload serves as release, except that
it used to close bugs too early (at uppload time rather than when
installed). I really did not see any advantages when I did have them
on my machine.
I no longer have these on my machine, so I can't comment any
further.
Jules> And (possibly) finally, there's dupload.
Like release. I use this one. It works well, and does not
close bugs prematurely. I have changed it to take a default
destination, so I do not have to give the --to master option if I
don't want to.
manoj
--
The chains of marriage are so heavy that it takes two to carry them,
and sometimes three. Alexandre Dumas
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: