I agree with Gerhard, the decoders dir is the place most likely changed by users and wiping it may have unwanted consequences. Maybe a user simply wanted to install a different version of libsrd to test a PD against, not expecting the decoders dir to be wiped in the process.
Personally, my prefered solution would be to ask the user when uninstalling as he/she is the only one who can make the desired choice when using makefiles. Is there a way to add a yes/no confirmation? If so, this is the route I'd go. Gerhard will probably rightfully point out that this may be interfering with calling "make uninstall" from a script. I have no solution to this, but I'd hope whatever mechanism used for asking the user would allow a default choice - in which case, I would choose to have the default be to delete the decoders dir to allow automated install and uninstall. Regards -Soeren On Sun, 2020-08-30 at 08:59 +0200, Gerhard Sittig wrote: > 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 _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
