Manoj Srivastava wrote:
> I have exressed what I felt lacking in the scripts before. For
> example, none of them seems to have a dry run option. so I can see
> what is going on without actually doing anything.
Interesting, I haven't read that objection from you before, but note:
--no-act
Do not really do anything. If used with -v, the
result is that this command will output a list of
what it would have done.
All debhelper scripts have this option.
> 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
Which is why I've introduced dh_checkversion, for those cases where you
really need a specific version of debhelper. I feel source dependancies are
really the way to fix this. Anyway, there are many examples of this same
problem completely unrelated to helper scripts - remember when patch's
usage changed and broke dpkg-source?
> (no packages using helper
> scripts shall build on my machine, for example).
Well, few packages tend to build on my machine here without gcc on it, but I
don't feel this points to a fundamental problem with the idea of having a C
compiler. ;-)
> My problem is that I think it is too easy to get dependent on
> these scripts, and not know exactly what goes on underneath. One
> never learns that way.
That's why all debhelper scripts have a -v option, and an environment
variable, to make them generate a listing of every single command they run
(and this is prominently marked in the example rules files for debhelper).
> The helper script generates make snippets that are called
>
> ./debian/snippets/blah.dist. If I want to modify it, I copy
>
> ./debian/snippets/blah.dist to ./debian/snippets/blah. The rules file
>
> is changed to include ./debian/snippets/blah if it exists, or else
>
> include ./debian/snippets/blah.dist.
The problem with this proposal is that as the snippets develop, become
robust, gain some features, you end up with, on average, about 500 lines of
extra stuff in debian/snippets (number roughly based on the number of lines
in debstd). Bloat. No worse than the debian/rules.in type proposals, though.
Debhelper sort of implemented this in the beginning, and included a way to
work around the problem of unnessesary bloat, but nobody has seen the need to
use it. I set up the debian/rules files for debhelper-using packages so the
PATH includes debian/ first. The idea is when you need to modify a debhelper
program, you copy it into debian/. I can think of perhaps two times total that
this was ever used, though, and one of the uses is by debhelper itself. It
seems that the concern about needing to modify the scripts/snippets just
isn't valid in everyway use.
Still, implement it, maybe people will use it. I was certianly suprised how
many people have switched to debhelper (~250 packages and counting...). I
think we still need to explore more possabilities here, we obviously hasn't
found a solution satisfactory to all yet.
--
see shy jo
--
E-mail the word "unsubscribe" to [EMAIL PROTECTED]
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED]
