On Sat, 8 Jan 2022 15:56:19 +0100
Didier Kryn <kryn@???> wrote:

> Le 07/01/2022 à 23:27, Hendrik Boom a écrit :
> >>     Install can be user-configurable, this is easy, but the package provides
> >> the way to uninstall and, for the uninstall to work, the install must be
> >> hardcoded because the source of the package cannot remember what the user
> >> has done at install time.
> > So the installer can create the appropriate uninstall script, based on
> > the parameters the user has provided.
> >
> > Then the uninstall script will have the user's own locations hardcoded
> > into it.
>
>     And what do you do with the uninstall script ? Is there any
> standard place to store it, under what name?
>
>     Currently, if you install hopman, you can get rid of the source.
> Then, if you need to remove it, just download the source again, unpack
> it and run 'make uninstall'. Having an uninstall script (actually a
> makefile) is not a bad idea. We just need a standard place to put it. Ideas?
>
> --     Didier
>

Hi,

Option A:

put it inside hopman itself.
It will get the cwd of the hopman binary,
assume that the prefix to uninstall
the other files is one level up,
create the paths and uninstall.
For example, installed in /usr/local/bin/hopman:
hopman --uninstall
are you sure? yes
getcwd returns /usr/local/bin
prefix is strrchr("/usr/local/bin", '/') => /usr/local
paths are:
prefix/etc/hopman.conf
prefix/bin/hopman/helperbin
prefix/bin/hopman
for list of paths
    if paths exists rm paths

Should work with all prefixes /, ~/bin, /usr/local, /opt.

Option B:
assume that path prefix is known at compile time
hardcode the paths in the binary
remove the hardcoded paths at uninstall time

Option B1:
it would be nice if sha sums of the files to be removed
could be stored into the binary to be sure to remove the right
ones (doesn't apply to conf files if there are some).

Just some horrible hacks, untested.

Ciao,
Tito