Re: Install Script Feedback

Steve Cookson - gmail <[email protected]>
Newsgroups gmane.comp.lang.perl.wxperl
Message-ID <[email protected]>
Hi James,

Thanks for putting it out there.  And great response.

My comments follow.

Steve.

On 20-10-2014 18:20, James Lynes wrote:
>
>
> I got the following feedback from posting the install script on Perl 
> Monks.
>
> Any thoughts? Willing to keep it updated as needed.
>
> I see 3.0.2 is available. Is it in the svn repository?
At the time of writing it is not there.  Look here to check:

http://sourceforge.net/p/wxperl/code/HEAD/tree/

If you look at my earlier emails, you can find a script which points to 
my own github repo with 3.0.2 in it.
>
> James
>
> --------------------------------------------------------------------------------------------
>
> I think that a couple of improvements can be made there.
>
> First of all,
>
>     find /usr | grep -i wx | grep -v -i python | grep -v -i soffice >
>     rm_w+x.sh # | Collect wx files. Exclude wxpython, and soffice
>     files sed -i -e 's/\/usr\//rm -rf \/usr\//g' rm_wx.sh
>     [download]
>     <http://perlmonks.org/?abspart=1;displaytype=displaycode;node_id=1104254;part=1>
>
> This looks scary and will break the packages installed in the system. 
> For example, wxmaxima, a frontend to a symbolic calculation system 
> written in LISP, will be deleted (but the package will be still marked 
> installed). MCabber, a jabber client not related to Perl or Wx in any 
> way, is going to get damaged, too.
It's true, it is dangerous.  When I'm running and re-running it, it is 
more important to me that I don't have to do a total rebuild each time, 
but we should try to refine this part of the script to make it safer for 
users.  If your Perl Monk has any ideas we could incorporate them.
> Manual cleanups should be done only in /usr/local;
I don't know about this, if that is true we could make it:

find /usr/local

instead.
> other parts of /usr belong to dpkg. Perhaps feeding the output of the 
> command to dpkg -S and removing the packages it finds is a better 
> idea, but you still need a way to filter the package names which 
> should not be deleted (perhaps removing only packages with names 
> matching 'lib*' will help for a start?).
>
> Also, you can save on the child processes by using find expressions 
> instead of grep: find /usr -iwholename '*wx*' \! \( -iwholename 
> '*python*' -o -iwholename '*soffice' \) should produce the same output 
> (and you can also use -iname instead of -iwholename to filter file 
> names only).
>
It takes a few seconds out of 45 minutes, I don't think it is significant.
>
> Another two relatively unimportant things are that you ask the users 
> to create a Perl directory in their ~, but don't use it much and 
> download wxPerl and Alien-wxWidgets in the ~ instead
>
You can update the wxPerl and Alien-wxWidgets directories to 
~/Perl/wxPerl and ~/Perl/wxPerlAlien-wxWidgets if you think is neater.
>
> and that you can save a lot of time on apt-get startup if you merge 
> all apt-get install commands into one.
>
I agree.  It's a trade-off between readability and execution.  Your 
format is more readable, but the merged format is easier to manipulate. 
Again, I'm not sure that the total execution time is much faster.  I 
don't mind which course we take.
>
>
> ----------------------------------------------------------------------------
>
> My response:
>
> aitap:
>
> Thank you for your reply. I'll get back to the original author and see 
> if we can improve the find section. The rm_wx.sh script is saved, so I 
> will take a look and see what was deleted unintentionally. The cleanup 
> commands would not be needed for a new install. For me, it was 
> visually easier to keep the apt-get commands separate as I was merging 
> several scripts and cross checking between them to make sure I didn't 
> miss anything. The Perl directory is where I put the install script 
> and other install files. The user is free to customize to their 
> installation.
>
> James
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.