Re: Request for advice: typespeed postinst
Ar 15/01/2004 am 12:27, ysgrifennodd Frank Küster:
> 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.
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
Reply to: