Re: Apology to the authors of helper packages
Manoj Srivastava wrote:
> Joey> That's why all debhelper scripts have a -v option, and an
> Joey> environment variable, to make them generate a listing of every
> Joey> single command they run (and this is prominently marked in the
> Joey> example rules files for debhelper).
>
> Heh. That takes care of one of my major objections to the
> helper packages. The opacity of the helpers was a major
> bugbear. Maybe it is time to install this and have another look.
This has been in debhelper since v. 0.01. Funny you just found out about it
;-)
> >> Second objection: The way the helper scrips are coded, amke the
> >> package dependent on them; if a different version exists on a
> >> target machine, the package may not build
>
> Joey> Which is why I've introduced dh_checkversion, for those cases
> Joey> where you really need a specific version of debhelper.
>
> How often to the interfaces to the scripts change? Is there a
> design document or something for them? (I have an uneasy feeling that
> the scripts may just have evolved, rather than being formally
> designed [nothing wrong with that -- most of my packages have evolved
> too]).
With the exception of new features being added to the scripts (enabled by
new command line options), we've only had one major interface change so far,
and I was careful to make sure it didn't actually cause any trouble (nobody
used the old behavior).
Debhelper is basically a second generation tool. A lot of the functionality
first appeared in debstd. When I was designing debhelper, I took a long look
at debstd, and this gave me the perspecitve I needed to really do some hard
thinking and design debhelper. There has been a little bit of evolution since
then, but with the one above noted exception, it has all been backwards
compatable, and my design seems to have held up pretty well.
There's no official design document for the scripts, (though there is an
official programming interface to their backend library, so people can
easily write new scripts using it - I don't think that's what you're looking
for). However, each of the scripts has a simple, well documented
functionality (see their man pages), and the only thing that makes me change
their behavior is if policy changes. In that sense, the debian policy manual
is the design document.
For example, dh_compress does one thing, and one thing only - ensures that all
files that policy says should be compressed, are.
> Yes, and in some ways, one should try to reduce these external
> dependencies. Also, the problem with a multitude of scripts doing
> little tasks is that one has to learn about all the scripts and the
> arguments; (like learning a [simple] new language).
One good thing about the debhelper scripts is that they are quite consitent
in their interface. They all take the same options, the options all do the
same things. You still do need to learn the names of about 20 new programs
to use it, however. (Luckily, the names are quite self-explanitory... guess
what dh_installexamples does..)
> To counter that complexity is the fact that there is a common
> code base that can be debugged and made robust centrally; and can be
> the before-the-fact arm of policy conformance code (lintian being the
> after the fact arm)
I love lintian! It found two or three places debhelper violated policy, and
it validated that debhelper is otherwise very policy complient. Made me
quite happy. :-) Lintian is so much more important to debian than
debhelper..
> Mean = 171 +/- 29.9454160294
> standard deviation = 123.468113293
> Without the kernel/rules file:
> Mean = 142.0625 +/- 8.20135596004
> standard deviation = 32.8054238401
>
> 500 is a bit much, don't you think? These rules file do not
> use any helper packages. I'd say that the correct figure should lie
> somewhere in between 150 lines ad 500 lines. And some of that would
> be required anyway.
Well, I assume your rules files are rather hand-crafted, right? I was
assumming the snippets were rather more general, which would tend to
increase their size at least two-fold, I'd think. Especially if they has
some sort of interface (ie, if they needed to parse command line arguments,
or parse config files in debian/).
Debhelper itself totals to about 1250 lines.
> However. I am unlikely to change unless there is a strong move
> to link a helper package to policy enforcement (I like my rules files
> well enough);
Hmm, what are you getting at exactly?
> and unless I an convinced of significant benefit to the
> process. I do feel better about the helper packages than I used to.
Good ;-)
--
see shy jo
--
E-mail the word "unsubscribe" to debian-policy-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@lists.debian.org
Reply to: