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

Re: Request for advice: typespeed postinst



Dafydd Harries <daf@muse.19inch.net> schrieb:

> Ar 07/01/2004 am 09:22, ysgrifennodd Dafydd Harries:
>> 
>> I'm in the process of adopting the typespeed package. I've made packages
>> with a new upstream version, and I'm happy with the packages I've made
>> overall, with the exception of the postinst file I've inherited from the
>> previous maintainer.
>
> Can somebody please help me with this? I'd really like to upload the
> package, but I'm quite stuck on this. Again, I've put a copy of the file
> on the web at <http://muse.19inch.net/~daf/misc/typespeed.postinst>.

copying in the old mail from the archives (which I don't have here any
more): 

>> - does the procedure for dealing with the previous broken version make
>>   sense?

Why don't you check whether these files seem to be the original ones
and, if true, delete them automatically? If the files are not too big,
you can include a copy of them in the new package and run a diff.

If you move the check to the config script, you can ask whether to
remove them; but if they are identical to the ones installed by the
package, then I don't think this is necessary: If they would have been
installed by dpkg, they would be deleted anyway upon the upgrade.

>> - should the various messages being printed to stdout use debconf?

Yes, and this should be moved from postinst to config, if possible. 

>> - does the high score file update procedure make sense?

Don't know, no idea about what has changed or if conversion is
possible. 

But, I think you should consider not to call "exit 1" after the
checks. This is really annoying, since it will stop the
installation/configuration of all other packages, too. I would try to
find a solution that does as good as possible, but prevents any
harm. For example, if your script encounters a situation that it cannot
handle automatically (also not with prompting in config), you could
replace the binary by a script that tells the user what to do.

What is it with these files "\*.old-\$\$: *.old-$$"? 

First of all, are they really dangerous? 

If yes, you should probably find something against this danger for any
situation, not only for the rare case of a package update. For example
fix the binary to just ignore them, or remove them if it finds old files
it should have removed upon exit.

Second, the code to find them seems odd to me:

,----
| OLDFILES=0
| for i in *.old-$$; do
|   if [ -e $i ]; then OLDFILES=1; fi
| done
`----

1. $$ will be replaced by the process ID of the current shell, that is
   of the postinst script. You probably want *.old-\$\$

2. The test -e will always yield true if the star in *.old-\$\$ expanded
   to something, i.e. if the loop is run at all. It is simply not
   necessary. You could do something like

   if ls *.old-\$\$ >/dev/null 2>&1; then OLDFILES=1; fi

   or

   if `ls *.old-\$\$ >/dev/null 2>&1`; then OLDFILES=1; fi
   
   (both the exit status of ls and the empty/notempty string work in the
   if construct).

Regards, Frank
-- 
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie



Reply to: