Updating tcz apps

[jpeters]

All utilities start out as scripts.  Until it's turned into an extension, it's of little use to the general community. Extensions can continue to be developed by the author....that's why there's a change-log.
 
 

[Jason W]

I really am caught between a rock and a hard place on this issue.  Scripts that exist in application extensions do simple things like stop or start a service, or other such things that are easy to look over and debug in the case of an issue.  Those are generally safe even in the case of a bug in them, and their sanity can be confirmed by a quick glance.  And the for programs themselves that we submit, we are compiling known code that many other people out there are using.

Such is not the case with a complex utility script that do things like install or remove packages, or format partitions, or stuff like that.  These scripts have to be done just right or a lot of damage could be done with their use.  Any of my such scripts of mine that I have posted to the repo have been discussed with the team and has their testing and approval of concept.  I cannot and do not post any of my own scripted stuff without the team, and namely Robert's, blessing.  In other words there is a QA and testing process that has to occur before a system changing utility script is posted to the repo for widespread use. 

We are probably the most open distro there is when it comes to community involvement, and we like it that way.  But we as the developers are responsible for what is available for users to download and use from the repo.  So for me to accept these scripts as extensions they would have to involve my testing and then my feedback to the submitter as to what needs to be done if the script is not sound.  It would demand a lot of time from both me and the submitter.  And I doubt that kind of meddling would be taken well.  So whichever path I took on this issue there were going to be hurt feelings. 

But scripts that are posted in the forum are free for folks to develop and use as they wish, and free from my involvement.  I think in the long run folks will like it better that way.

[jpeters]

Update can download md5 files for deps or extensions in the tce dir.  to /tmp/md5 (which it later deletes)  It performs a md5sum check, and files a report in the /tmp directory. Other than that, it
wgets a selected extension using tce-load wget install.   Does any of that sound overly risky?  (sure seems a lot less risky then tce-uninstall)

Update has become one of my most used apps...if there's no interest in it, that's fine with me.  I can check my tce-dir for update candidates and update a batch of extensions in seconds.  

Regarding leaving things in tips & tricks.....as far as "update" is concerned, nobody is going to read through 45+  posts to figure out what to copy....if they can find it to begin with after it's buried.  For most simple scripts, no extension would be necessary. 

[Jason W]

It is not that there is no interest in updating apps, or in your script.  And I agree that for simple scripts no extension would be necessary.  And I have not said that updating apps is not a good idea.  
But while we are discussing this, let me point out what I see in your script that can leave a user with a broken system, at least broken extensions though not base.  First, you are not umounting the tcz file itself before deleting it.  That may not be itself cause breakage in extensions, but it is not a good practice.  What I see that will sooner or later cause extension breakage is the fact that your script does not remove the symlinks from the old extension before loading the new one.  When a tcz is loaded, it does not overwrite existing files or symlinks.  Say for example you updated gtk2.tczl to version 2.14.8 from 2.14.7.  When you run your update script, none of the existing symlinks would have been overwritten.  So the file ./usr/local/lib/libgtk-x11-2.0.so would still be a symlink pointing to ./usr/local/lib/libgtk-x11-2.0.so.0.1400.7 when that is an old, dangling symlink that points to a no longer existing file.  The new lib would be /usr/local/lib/libgtk-x11-2.0.so.0.1400.8 but the .so file will not point to it.  Therefore gtk2 apps would no longer work.  
It is not that I care that tcz-uninstall was not called on in this script, but the removing of symlinks in the system and the umonting of the tcz file before deletion is needed.
And I agree that hunting through many posts to find the latest version of a script is not ideal.  I do not have a problem investing time to work with people in honing scripts for the community to use.  And if we did accept system changing scripts in the repo they would need to start in the "programming and scripting" section  of the forum, develop and mature there with team input, and then be candidates for uploading.  It is great we have a community that invests their time in developing extensions and utilities to further TC.  I would like to help encourage that and have a process that facilitates the development of scripted utilities and tools.  Like mentioned before, this distro is young and things are still evolving.
There are several criteria that a script should meet for it to be a general use script in TC.  One is that no hard coded paths are to be used, the variables defined in the system should be used instead.  In this script I see a hard coded ftp download directory when it should reflect the mirror chosen at the control panel.  One tricky part that my uninstall scripts also do not cover is the handling of WM menus besides JWM.  But that can come in time as those details settle, and there is a tool in the works that will help with that.  A script needs to work across all modes of operation or be confined to a single defined one.  Yours of course is for PPR/TCZ.  And, obviously, the utility should not leave a user with broken extensions or worse put a user at risk for lost personal data.  
I agree that tce-uninstall is somewhat "out there".  I was advised against it but I pushed for having it.  There is a design flaw in it that is not correctable, hence my decision to retire it. 

[jpeters]

The idea behind  'update' intentionally was to make it simple and fast, so it avoids
elaborate  uninstall features already available in tcz-uninstall. Once in the tce directory, that issue presumably would be handled after a reboot.  For all apps in my tce directory, things worked without rebooting (I consider that to  be a fringe benefit).  I added the fix to menus and icons as an afterthought when Robert made mention.  Still, as noted, I can update a dozen extensions in about a minute.  If I had to reboot to get a link to work, that's only another 15 seconds.  

The path used for downloading md5 files is  "ftp://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/"   Is there a better way to script this? It seems to work well.  

I'm not aware of anything in 'update' that would lead to file corruption or loss of data, so don't know what you're referring to on that.  Update uses tce-load wget install.  It deletes the selected extension from the tce dir so that it can be installed, which is  what I would have to do manually anyway for wget to install a new copy.  

I appreciate your comments.  I posted everything about update in the thread, and after about 1000+ views, have not received feedback about problems other than the possible links issue noted in your post.  

[Jason W]

The data loss I was referring to was not directed at this utility but as a general condition to avoid.  It would be possitiblithy with other operations that are not part of update. 
The deletion of old symlinks takes an almost unnoticable amount of time with find and xargs, and would really be necessary for a clean update of apps.  If rebooting were required, then all that really would have to happen is a removal of the *.tcz* files in the tce directory, the rest would be good on a reboot. 

There are system variables for the mirrors, and I can list them when I get home to TC.
That way a user would be using his selected appbrowser mirror.

At work, have to go.

[jpeters]

I see...you want to read the /Mirror/ path from /opt/.tcrc instead of writing it in directly.  OK
note: That only was for the md5.txt downloads.  The script already uses /opt/.tcrc for the install:

Code: [Select]

case $APP in
 *.tce* ) sed -i 's/tcz/tce/g' /opt/.tcrc ;;
 *.tcz* ) sed -i 's/tce/tcz/g' /opt/.tcrc ;;
esac
tce-load $APP  wget install


[Jason W]

Ok, I see.

[jpeters]

use /MIRROR/  for md5 download

[Jason W]

On the subject of removing the symlinks, the boost extension has 6737 symlinks created.  It takes a quarter of a second to remove them all with find and xargs on a 2.6ghz machine.  That is not bad overhead even with the largest extension (in number of files).  Also, a lazy umount (umount -l) of the tcz would make things good as deleting a mounted file is not the best practice.  This would prevent the need for rebooting in almost any circumstance.

[jpeters]

ok...this umounts -ld & deletes symlinks.  

[bigpcman]

I admit I may be an unusual user but I count on being able to uninstall apps without a reboot and I count on tce-uninstall to remove the app correctly without having to worry about residual effects. Any remaining files that tce-uninstall leaves behind can be removed with a wrapper script.  However, I do see the merits in the update script. It does serve a valuable purpose. It would seem to me these two scripts could be combined in some way to produce the best of both worlds. I would love to see the update script offer the user the choice of using the comprehensive tce-uninstall or the quick and dirty uninstall. How about it guys?

[jpeters]

At this point, 'update' shouldn't need a reboot.  I use tcz-uninstall for a different purpose, like when I'm trying out a new ext and need to keep uninstalling/reinstalling.  Update only works when you want to replace an existing app with a newer version that's in the repos.  Given all the related features (update-check, etc),  it might be best to leave it as its own tool.  If you've already run tcz-uninstall, might as well just run appbrowser. In fact, 'update' wouldn't work at that point, because the extension needs to already exist on your computer. One more reason....'update' works for all extensions, not just tcz, so you'd be talking about adding tce-uninstall as well (....uh...no thanks....  )

[jpeters]

Although I removed symlinks, I still have a question as to why that's necessary when updating vs/ uninstalling.  Since it's only a link, it will simply connect to an updated file, so shouldn't have to be deleted and re-written.  The only problem I could see would be a previous link that is no longer used, which wouldn't effect functioning of the updated app at all....and the dead link would remove itself after the next reboot.  Maybe I'm missing something...

Edit: I guess it doesn't....I'll try umounting first and see if that works.

[jpeters]

After testing, I found as long as the extension was umounted, the links correctly displayed the updated content, as expected, so extensions would work without deleting the symlinks.  Deleting them simply removes any that are no longer used, which would probably be rare for updated apps, and in any case removed after rebooting.  (although no harm in removing them, either)