Skip Menu |
 

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 105551
Status: open
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: perl [...] localhost.localdomain
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: Strawberry de(installer) data loss
Download (untitled) / with headers
text/plain 432b
When deinstalling strawberry perl with the .msi (which is required even when upgrading to a newer version) it happily deletes all user files from the directory tree, most prominently the whole /site directory. This behavior results in data loss of user files put there. A deinstaller should *only* delete the very same files it installed files! Any "remove all remaining files" should be strictly opt-in and sanctioned by the user.
Download (untitled) / with headers
text/plain 618b
On 2015-06-29 04:27:33, email@alsigma.com wrote: Show quoted text
> This behavior results in data loss of user files put there. A > deinstaller should *only* delete the very same files it installed > files! Any "remove all remaining files" should be strictly opt-in and > sanctioned by the user.
If you mean INSTALLSITELIB (sorry, I don't speak strawberry, but that's the term ExtUtils::MakeMaker uses), there shouldn't be any data files there, and it *is* fair game for a re-install of perl to wipe everything there to reinstall distributions. Any code you are using that puts mutable data files there is wrong and should be fixed.
From: email [...] alsigma.com
Download (untitled) / with headers
text/plain 1.6k
Wellyes, I expected someone to say so. Reminds me of the "files without backup aren't important" mantra which somehow doesn't quite hit the mark in the real world(tm) :-p Personally, I'm dropping exiftool files from their zip distro in /site because this is where it's found by default by everything. I dunno if there are any perl conventions that prevent users from modifying this tree, seems the right place to me. However(!), after having worked a long time as a dev building msi installers, I an very positive wiping user data is an absolute no-go, wherever it is found (and users are rather creative for finding odd locations, take me for example :-)). This is simply common sense as the risk of sending important data into oblivion far outweighs the risk of leaving some config files behind. And in the case of strawberry, it's not even that as the /site dir is empty by default. My guess is that this is not broken by design but simply an oversight or lack of time to test it ... the same reason why the installer is unable to update a distro (like 5.20->5.22), w/o telling the user to manually de-install the old version while msi script is designed to do these things automatically. On Mon Jun 29 12:52:03 2015, ETHER wrote: Show quoted text
> On 2015-06-29 04:27:33, email@alsigma.com wrote: > If you mean INSTALLSITELIB (sorry, I don't speak strawberry, but > that's the term ExtUtils::MakeMaker uses), there shouldn't be any data > files there, and it *is* fair game for a re-install of perl to wipe > everything there to reinstall distributions. > > Any code you are using that puts mutable data files there is wrong and > should be fixed.
Download (untitled) / with headers
text/plain 542b
On Mon Jun 29 07:27:33 2015, email@alsigma.com wrote: Show quoted text
> This behavior results in data loss of user files put there. A > deinstaller should *only* delete the very same files it installed > files! Any "remove all remaining files" should be strictly opt-in and > sanctioned by the user.
...And should warn that if unchecked, uninstallation can take 3 hours or more, so as to encourage checking it. (I remember it taking 3 hours before implementing current behavior back in 2009, when I would install a large number of modules on my own system.)
Subject: MSI - add option (checkbox) to not remove site dir during uninstall
Removing c:\strawberry\perl\site + c:\strawberry\cpan (on top of other installed files) is currently a feature.

As mentioned by Curtis it is so for approx 5 years and you are IMO the first one complaining.

I am not against making it optional but somebody should write and test the WiX/MSI code.

Just to make it clear: the main reason for removing site dir is the fact that after upgrading to the new major version all XS modules installed in site dir will be broken.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.