Bugzilla – Bug 7972
Make sure a fresh install always creates a working system
Last modified: 2009-07-31 10:20:09 UTC
I believe the following enhancement request is very important to help usability for "normal" users: Clear critical data, e.g. template cache and plugin-data.yaml upon installation When SC get's a fresh install, it should be made sure, that the user gets a running system, even this is at the cost of losing configuration data. Currently this is not the case. There are at least two cases where uninstalling and re-installing SqueezeCenter does not lead to a working system configuration: - When there are broken template files in the template cache - the template cache does not always get cleared upon re-install - When installed plugins are deleted dureing the uninstall, they are not necessarily removed from the configuration, which means you can not upgrade to a new version of the plugin (plugin-data.yaml issue; see bug 7971 for setails: https://bugs-archive.lyrion.org/show_bug.cgi?id=7971) I think SqueezeCenter should always create a working system when installed correctly, we cannot expect end users to be able to manipulate cache files and we cannot expect them not to break the system.
I think we had this topic before: should the configuration survive an uninstall or not? Maybe we should at least flush the cache folder and tell the user about what to delete if he really wants to start from scratch.
Micheal, this is NOT about the configuration! The cases I describe will not change the configuration. It's about leaving you with a running system after a fresh install. If you think keeping the configuration will also get in between you and that goal, maybe a persistent config backup with an option to import the backup after a fresh install would do.
> Micheal, this is NOT about the configuration! "even this is at the cost of losing configuration data." - configuration data can in theory keep your SC from starting (as you noticed in the inital description). Thus it's part of what should be removed. But I agree: at least the cache should be wiped. It's not only useless after an uninstall, but it's also rather big on the disk, and re-created after an install. BTW: you mention OS "other". What OS are you (personally) seeing this issue on? Fletch - is the .rpm file taking care of removing cache files et al.?
I personally experienced the template issue under Windows XP and Ubuntu, I never re-installed SC under OSX. The plugin issue (that's the other bug, isn't it?) has not shown up on my own systems so far, but I had reports on OSX (various), WinXP (various) and Synology DS107 (Linux, one).
(In reply to comment #3) > Fletch - is the .rpm file taking care of removing cache files et al.? > On uninstall, neither the RPM nor the Deb remove the cache (or the prefs or logs for that matter). IMO, this is normal. RPMs and Debs usually remove any files that they installed, but leave behind files and directories created by the application. This can be changed if that's what we really want to do. I have a general concern about ever wiping the cache without any user interaction. There are a number of plugins that write opml files to the cache (I think when the playlist dir doesn't exist or is not writable). Wiping the cache will destroy this user data. How often do the two cases described in the initial bug report occur? Couldn't SC be fixed to gracefully handle these?
imho we should be allowed to wipe the cache any time. Nothing should be lost except time. If playlists get written there, then we have another issue. The whole idea of having a cache folder was to store "volatile" data. Anything else should be stored elsewhere.
(In reply to comment #6) > imho we should be allowed to wipe the cache any time. Nothing should be lost > except time. If playlists get written there, then we have another issue. The > whole idea of having a cache folder was to store "volatile" data. Anything else > should be stored elsewhere. > I agree. BTW, this is why the RPM and Deb use /var/lib/squeezecenter/cache instead of /var/cache/squeezecenter. We felt that it didn't really meet the FHS definition of a cache.
Dan - could you please comment from the support's point of view?
To be honest, we never suggest to a customer they simply uninstall and reinstall. We always add instructions on how to delete all the files that remain after they uninstall, which would include the Cache folders and Plugin folders. So in a way we sidestep this issue. However, the reason we do this is to ensure that we are starting with a *truly* clean install. As such, I'd be perfectly happy if we nuked all remaining folders on uninstall, whether they were created at install or after install.
> As such, I'd be perfectly happy if we nuked all remaining > folders on uninstall, whether they were created at install or after install. I'll try to make this an optional step. And it will move configuration (not cache) to a backup folder instead of deleting. I'm reluctant nuking things.
How about keeping the configuration and ASKING upon installation on whether to apply it or create a new one? This way you can do try to keep the old one but there's still a way to create a working system if that fails. An alternative could be to create an option to import the old config later.
> How about keeping the configuration and ASKING upon installation on whether to > apply it or create a new one? IMHO "industry standard" is asking during uninstall. Install should be as simple as possible, doing what most would expect it to do silently. If somebody really wants to get rid of his installation he'll have to run uninstaller and click that option.
(In reply to comment #12) > > How about keeping the configuration and ASKING upon installation on whether to > > apply it or create a new one? > > IMHO "industry standard" is asking during uninstall. Install should be as > simple as possible, doing what most would expect it to do silently. If somebody > really wants to get rid of his installation he'll have to run uninstaller and > click that option. I don't know about "industry" standard, but agree that it's very much a standard in Windows environments - possibly because everyone uses the same two or three popular software packages to build their installers. I would make getting rid of configuration backups a manual step - just by sitting in a backup folder they should have zero affect on anything SqueezeCenter does. They can be recovered by moderately tech savvy users or with the assistance of tech support. In regard to comment #6 - Aren't the bundled MySQL's database files also in the cache folder (on Windows installations, anyway)? If what you say is the goal, then these files should be relocated. You need to think ahead to the day when non-recoverable data is kept in that database. Things like user ratings, etc. Deleting the cache folder in that case would delete data that is very much non-volatile.
> In regard to comment #6 - Aren't the bundled MySQL's database files also in the > cache folder (on Windows installations, anyway)? If what you say is the goal, > then these files should be relocated. You need to think ahead to the day when > non-recoverable data is kept in that database. Great comment! If only that day was a bit closer already...
Dan - could you please define _if_, and if, _how_ you'd like this to be implemented?
Well, I think we may be describing two very different installation options here: 1. A user uninstalls the software, then installs the same or updated software. 2. A user installs updated software on top of the old. So far all my comments have only dealt with item #1 above. In my opinion, if a user chooses to uninstall any software, then deleting any and all files is fair game. Further, I think that's preferable to leaving files behind. Jim's point in comment #13 seems to speak to item #2 above. The only time we'd care about preserving data of any kind is if we're upgrading the software, yes? In which case I agree, we should be copying over the old prefs and database, which we already do. Michael-- as to your request, I'll confine your question to just item #1 above-- purely uninstalling the software. Do I think this would be helpful? Yes. And I think your suggestion of a checkbox when you're uninstalling would likely be the easiest and least bothersome to the user.
Let me please add the critical alternative 3: 3. A user has screwed up his or her installation and cannot do a correct uninstall. In this case he or she needs a way to get the system back to work. Please let's not assume everything will go well all the time.
Reinstalling on top of an existing installation should not by default wipe out a configuration. Sorry. I have no problem if the installer automatically clears the cache, but not configuration options or the library database. Think also of users running nightlies and using the Windows installer. Do you think they'll want to clear their configurations and/or database each time? Not likely. Maybe during the installation process, if you detect a prior installation, you could _ask_ users whether or not they want to clear all previous settings and data. But you can bet that will pose a support nightmare in itself when tens of thousands of users doing a x.x.1 to x.x.2 upgrade are asked if they want to erase their configurations and many of them mistakenly do so.
I didn't state that any configuration or databases should be deleted. But a way to get to a running system will be needed. One way could be to identify that there are remains of an old installation on the system and ask the user what to do with it.
> 3. A user has screwed up his or her installation and cannot do a correct > uninstall. In this case he or she needs a way to get the system back to work. The uninstall fails - how should it clean up itself? If we could manage this, then we'd rather prevent the failure... BTW: I've rarely to never heard of anyone failing the SC uninstall. Did this happen to you? If so: in what way did it fail?
So here's my plan: - install remains unchanged: if there's a configuration/cache/whatever, just use it - during uninstall give the user the option to wipe anything ("[x] remove all configuration and cache files"). If he doesn't check that box, the the uninstall will work as before, leaving all but the program folder behind Now I'll go figure out how this is doble at all.
I didn't mean to remove stuff on a failed uninstall but on the INSTALL. Remember, the request is to make sure that you can always generate a working system at setup no matter what happened before. I think offering an option on whether to wipe old data or not (at install time) is reasonable, so if the first install fails, a second try can get you a running system. There are a lot of reasons why an uninstall could fail: manual deletion of part of the SC directory, of the uninstall information, corruption of the registry etc, etc. We should never assume that things can not go wrong. They always can.
change 20587 - optionally remove all SC preferences, logs and registry keys (Windows only)
This bug has now been fixed in the 7.1 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC