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 [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED]
