:: Re: [DNG] merged /usr breakage
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
Date:  
To: dng@lists.dyne.org
Subject: Re: [DNG] merged /usr breakage
Le 08/01/2022 à 17:18, tito via Dng a écrit :
> 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).


    If you install in /usr/local, everything is standard and can be
hardcoded and install/uninstall is done by the owner of /usr/local. But
the launchers are to be installed/uninstalled by every user in their own
~/.local

    When installing on /opt your method seems best. At the end the
uninstall script must delete itself, but there is certainly a trick to
do that. Note however that it adds quite a lot of complexity to the
application, plus one file to install: the uninstall script. In this
case, every user must install the launchers, but also update his PATH
and MANPATH.

    When installing in the user's home, your method can
install/uninstall everything and is also responsible of his PATH and
MANPATH.

--     Didier