[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New maintainer's packaging - bewildering variety of information



On Sun, Aug 16, 1998 at 12:17:45PM -0500, Manoj Srivastava wrote:
> 	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. 

I'm going to add my comments (as a fairly new maintainer) all around.  I use
debhelper because IMO it makes the debian/rules file more readable but I've
found places it doesn't work so well and I have to resort to some pretty
ugly hacks to put things in place for some of the nastier of packages I've
looked at and played with.


> 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

While this is true of debstd, it's not really true of debhelper as much. 
You still have to know enough about the package and the packaging format to
put the right debhelper commands in the right place, and not every situation
has a premade command.

Some of those arcane tasks may be better done by hand so you understand how
to do them.  Perhaps if you already understand them, it may be better for
you to use debhelper because it's easier to let it take the grunt work out
of packaging.  This is certainly a matter of taste.


>    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

Of course, if NOT maintained, debhelper could end up like debstd, which is
kinda behind on policy.  If you used debstd before and wanted to move to
debhelper now, you're going to have a time doing it.  They are different
enough that there is no simple upgrade, though there is a method of
returning the list of debhelper commands to that would do approximately what
debstd would do in the same circumstances, but what it returns needs much
pruning.


> Disadvantages:
>     i) One becomes dependent on them, and does not know what is going
>        on

This was the case with debstd, but with debhelper you know what the rules
file is doing because it does only what you tell it to.  It's not one magic
program that does everything but a series of smaller scripts that do
different things.  It's very easy to go from debhelper to roll-your-own and
vice-versa.  This wasn't the case with debstd.


>    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)

With debhelper, you can do something by hand if it's better done by hand or
yourself if it's better done by yourself.  It allows mixing of debhelper and
your own commands pretty easily.


>   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]?) 

The bugs issue and seperate commands issue can be problematic, but
debhelper's commands are easy to learn fortunately and the package is
updated frequently.


>     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)

This is actually more a flaw in Debian's source package format than
anything.  There is currently no method in practice (several in design as I
understand it) for determining what is required to build a package as the
maintainer designed.  We've all been bitten by this once or twice I'm sure.


> 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

Easier to get it right if you know how to get it right.  If you DON'T know
all of that, you're in for some trouble because you'll have to learn how to
do it right first.  =>  That may not be such a bad thing of course, but it's
still an issue for those who haven't much spare time since Debian is in most
cases worked on in developers' spare time.


>     ii) One can exercise precise control, and can be more flexible 
>    iii) One gets to know Debian policy rather well

These are definate plusses, other than perhaps that there's a high margin
for being left behind on policy versions.


>     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

These two don't really count.  iv is the same for both methods and v is your
opinion..  =>


> 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)

Again, is this such a bad thing?  Perhaps this is how it should be.


>     ii) You have to keep track of policy, and change all your rules
>         files when policy changes

At the same time, you should be keeping track of policy anyway, right?


>    iii) More prone to making errors (human error) than a script is

Human errors happen.  There's not much you can do about it.  The human
errors that can happen in the roll your own rules so easily can as easily
happen in the debhelper package.  Ever release a version of a package with a
"stupid error"?  Lots of people have.  We're only (mostly) human aren't we?


> 	I, in my inimitably biased fashion, prefer to think my rules
>  as hand crafting package, rather than a cookie cutter approach ;-)

debhelper is less a cookie cutter approach than debstd was.  What you use
depends totally on what is best for you, you're the maintainer after all. 
Both are very viable solutions and as I said, you can convert between them
easily.

I've tried to play devil's advocate here and question all points.  Perhaps
between your comments and my responses, people might be able to make an
informed decision.  Or perhaps, someone may have further comments.  I
certainly welcome any that anyone may have.

Attachment: pgpJn8wgkibFP.pgp
Description: PGP signature


Reply to: