On Sat, 2020-08-29 at 22:14 +0200, Wolfram Sang wrote:
>
> From: Wolfram Sang <w...@kernel.org>
>
> Decoders were left when using 'uninstall' target.
>
> Signed-off-by: Wolfram Sang <w...@kernel.org>
> ---
>
> Found this while trying to remove outdated (because renamed) decoders
> which triggered warnings. I hope this is proper automake.
>
> Makefile.am | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9e15c30..0cab4e3 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -110,3 +110,5 @@ install-decoders:
>
> install-data-hook: install-decoders
>
> +uninstall-hook:
> + -rm -rf $(DESTDIR)$(DECODERS_DIR)
> --
> 2.20.1
Minor make nit: Was to understand that $(RM) is more portable,
and might be preferred. But could not find examples in existing
rules within the minute that I spent searching. It's pre-set in
GNU make, can't speak with certainty for automake on other
platforms that don't use GNU make.
This subject might be a sensitive one. Will users get angry when
*all* directory content gets removed, including the files that
were added by other means than libsigrokdecode installation?
When the install script gets extended to optionally remove
decoders: Will users be surprised if _some_ of the content
remains, when the source has changed between installation and
uninstallation and thus won't remove what got installed before?
(This may be the situation that you faced.)
Either choice of broad or fine selection what to remove could be
as wrong as any other one might come up with. The most reliable
option is to "somehow install" the files _and_ track what got
installed, to remove that very installed content (and maybe only
if it wasn't modified after installation -- the change may have
been expensive and worth keeping). This is probably beyond a mere
make rule. Touches policy, and is what package managers do and
are good at.
If you ask me, I'd add another "data uninstall" target for
symmetry, and add a -u option to the Python install helper script
to uninstall those files which ship with the sources. This would
work for packagers, and developers when sticking with one version
or similar content across versions. Doesn't cover your specific
use case, and neither prevents the loss of local manipulation
after installation. So it combines all disadvantages of either
approach. Must be acceptable as everyone gets just a little
unhappy. :-P
As long as automatic support for most appropriate removal is
missing, it's probably most robust (and needed rarely enough)
when those who install from source just go to the directory they
install to (it's likely to be something isolated and local
specific), and decide when to remove and what to remove. Lets
them keep what's important to them, and can be as simple as just
removing the single directory, or can selectively remove a few
decoders which became obsolete.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
