Ar 15/01/2004 am 12:27, ysgrifennodd Frank Küster: > Dafydd Harries <[EMAIL PROTECTED]> 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.
Unfortunately, I don't have a copy of these files. I tried snapshot.debian.net but it doesn't have the version of the package which contained the bug (0.3.5-3). > 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. I'm tempted just to remove this part of the file. Is this unreasonable? Woody has a more recent version than this (0.4.1-2.2), if that makes a difference. > >> - 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. Well, if the binary format changes, the old scorefiles will surely be useless. The current update procedure is to replace empty score files which newly generated ones while retaining non-empty ones. > 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-$$"? These are the backed-up score files. I didn't choose this, the previous maintainer did. > First of all, are they really dangerous? There might conceivably be a security problem, but none that I can think of off the top of my head. I'm thinking that if the script really needs temporary files, I will use tempfile to do it securely. > 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. My understanding is that the binary doesn't interact with these files at all; they're specific to the script. -- Dafydd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
