Re: Apology to the authors of helper packages
Hi,
I think I'm going to be flamed for this ;-). *Still think I am
entitled to my opinions). In any case, whether people do or do not
use helper packages is their own decision. I reserve my right to my
opinion.
>>"Craig" == Craig Small <csmall@scooter.o.i.net> writes:
Craig> Manoj Srivastava wrote:
>> This is old hat, and I think it should not be raked up again,
Craig> [usual stuff from Manoj - Christoph deleted]
usual stuff?
>> Alos, I was not asking for expertise, but mere competence. I know
>> better than to ask for expertise. Competence should not be hard to
>> achieve; and should not be too onerous for one packaging a Debian
>> package.
Most packages do not require very complex scipting. I assume
if shell scripting is not their forte, people shall not package shell
script intensive packages. There are tonnes of examlpes of the
commonly used shell scripts (pre-post inst scripts, and how to add
info docs, or register with suidregister, or add menu entries, or
whatever. No one needs code most scripts from scratch.
Craig> As someone who wrote some of these helper scripts Was recently
Craig> (6 months ago?) a new developer
Craig> I can see where the problem is, a lot of people here have
Craig> forgotten how hard it was for them.
No, I have not forgotten. When it was that hard for me, I did not
have the inmitigated gall to be a developer; I do not start packaging
things for general consumption while still in the novice stage.
Craig> You don't like helper scripts and whinge about them? Now we
Craig> have a problem. Saying that all these scripts are no good is
Craig> not what I call constructive, but saying that script Y breaks
Craig> policy 1.2.3 because it does this instead of that is
Craig> constructive.
Whinge? what does that mean? It sounds, umm, pejorative,
somehow.
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.
______________________________________________________________________
withecho () {
echo " $@" >&2
"$@"
}
action='withecho'
while [ $# != 0 ]; do
value="`echo x\"$1\" | sed -e 's/^x-.//'`"
case "$1" in
-h) usageversion; exit 0 ;;
-n) action='echo' ;;
esac
shift
done
eval "$action cvs -q export -d $pkgdir -r $cvstag $cvsmodule"
______________________________________________________________________
See? when -n is supplied, no action is taken. Can be used to
pass the -n option to make.
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 (no packages using helper
scripts shall build on my machine, for example).
I do have an alternative proposal for doing something like the
helper scripts. Maybe if I have time. Even then, it may be better to
learn how to fish; rather than getting a fillet from the helper
scripts.
Craig> Also, saying that all Debian developers must know shell
Craig> scripting back and front is not a good idea either. How about
Craig> helping these people?
I have no problems helping people. I just am uneasy about
them putting code on my machine.
Craig> I remember what I nightmare it was building packages, it still
Craig> is very difficult for a lot of people.
It is very difficult for me to speak serbo-croatian. I do not,
however, try to pass myself off as a translator. Why does one have to
so far exceed ones limitations? Why the burning desire to fob off
medicrity on the world? Why not wait and learn the tools needed to do
the job before signing up
Craig> I think a lot of us have forgotten the developers out there,
Craig> trying to package stuff correctly but not sure how.
Then they should learn. Spoon feeding people does not help in
the long run. Hmm. Maybe it does. Thats the basis of Microsofts
business model.
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.
manoj
=====================================================================
The alternative is to have the script generate snippets in,
say, ./debian/snippets.
__> ls ./debian/snippets
vars.dist vars
man.dist
lib.dist
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.
Only the blah.dist files are evre overwritten, so user changes
are never lost. Since the snippets are part of the package, the
package is self sufficient.
One just re-runs the helper scripts to update the *.dist
snippets, and use diff to merge any upgrades into locally changed
files, if any.
Since they are make snippets, ake -n is a dry run.
Since they are make snippets, it is easy to see what they do
(well, IMHO ;-)
=====================================================================
--
The pedestrian works where I work. She is a standards
coordinator. Funny she should be the one I hit.
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
--
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: