Updating tcz apps

[mcewanw]

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. 

TC is being developed very quickly, which is fantastic, but a nightmare to keep up with it all. Tonight I decided to upgrade to the latest, but realised that I had no clue which of my tce and tcz extensions needed upgraded. With dialup (which is all I have) it is a major job having to re-download everything so some auto-checking upgrade script is an absolute essential in my opinion. Admittedly, I didn't use jpeters upgrade script on this occasion, but instead spent hours actually re-downloading everything by hand. But that was unsatisfactory - next time I want to use the script!

However, it is a relatively complex script, and I am scared to use it because even the best programmer can easily leave a bug or two, which could cause a major disaster! So, on one hand, I absolutely agree with JasonW that the TC core team need to carefully vet any such script, and its nature makes that quite a lot of work - but I do feel that it is really an essential utility for a distribution such as TC which comes in the form of a "mechano set" for building complex configurations out of many parts - you NEED an upgrade facility for such a distribution, surely?

I also think it is a great pity if the tce or tcz uninstall scripts are to be "retired" such that they are no longer available. What a waste of your work! I don't agree that such a script necessarily has to be able to deal with ALL tc modes of operation - nice if it can be so general purpose, but it's useful anyway, for whatever mode it works with. The users just need to be educated about when it can be used and for what modes, and when it shouldn't be. Surely all the wm menu-related issues will soon settle down and make it worth revising the uninstall scripts at this early stage in the development of TC.

I really do think that the only thing I'm not quite satisfied with when it comes to using TC is that, by default, appbrowser doesn't allow me to re-install an already installed extension (with an updated version). First the user needs to uninstall the old extension - so that IS a vital system facility that badly needs to be provided. That's my opinion anyway. I can assure you that jpeters isn't the only user who felt that a facility for upgrading existing extensions was needed. I also had that feeling and was glad to notice work was being done on it. But, yes, upgrade is a relatively complex script and, like all such system-level scripts, a potentially dangerous one - it thus NEEDS to be designed either by the TC core development team or under their tight control in terms of collaboration and testing. I also agree that it's not satisfactory, to leave symlinks hanging around, whether or not such stray links seem to have no adverse effects - such script behaviour is just inviting unforeseen potential trouble. Having said all that, jpeters work is to be applauded and encouraged - I didn't see anyone else trying to provided the functionality of "upgrade" and somebody needed to!

Summary... I vote strongly for an "upgrade of existing extensions" facility, which really should be provided with the TC core system in my opinion (and hence rigorously designed and tested at that level). I can' say one way or the other if jpeters utility is the best way to provide that facility or not, but "retiring" any such script (or hiding them away in the depths of the forum) is not the way to go for such an important omission in what TC core currently offers.

[roberts]

A very conservative and safe upgrade script is currently being tested by TC team.
My plan is for it to be available in the final 2.1 release.

[jpeters]

The update script is safe, and works well for checking updates and for updating apps.  Safety was never an issue.....some people felt it didn't do enough "deleting" , so I added features so that you don't need to reboot.  It doesn't screw with deps unless you ask it to, but will tell you what deps need updating.  That's one of the reasons it doesn't break your system.    

[roberts]

We will never agree on this. I am of the opinion that one should not attempt to upgrade extensions that are being used. A simple method will be made available to upgrade all extension be they tce or tcz in batch fashion.

 

[mcewanw]

Very conservative and very safe sounds good to me for this kind of purpose. I'm glad to hear that is being worked on. I can understand jpeters' feelings though. Nevertheless, such a script is clearly core functionality and needs to be carefully designed and tested at that level regardless of how good or bad any user-designed and developed scripts might be. A trusted repository works on the basis of careful testing and vetting.

As far as I see it, open source just means that the source code is published, and that anyone can fork a project, but it doesn't, I realise, infer that users can insist on their code being included in official repos (especially when the code is concerned with core functionality). But it would be good to have "unofficial, or "user-repos" too, so that general users of TC can share their own enhancements, at user risk, some of which might (or might not) later be adopted and incorporated into the official core. That's just how these things work, but then, I didn't start the TC project - I'm just a user, but hope that I sometimes manage to contribute something useful.

Anyway, until something else is provided, I'm planning to use jpeters script, and might even modify it for my own specialised purposes - which is another reason that easily located user-shared scripts are so handy.

[jpeters]

We will never agree on this. I am of the opinion that one should not attempt to upgrade extensions that are being used. A simple method will be made available to upgrade all extension be they tce or tcz in batch fashion.

Sorry, but this is the first I've heard that there was a disagreement. I think I responded to every suggestion on the thread. The tcz extensions are umounted before being updated, but that was only so that rebooting would be unnecessary.   (can you be "using" an extension after it is umounted? )

edit: I wrote tce-remove in case I wanted to delete tce.list  files before reinstalling, but from the testing I've done, it doesn't seem necessary.

As anyone knows who has looked at the script, 'update' works for both tce and tcz extensions. Doing 'batch' would be trivial, since it only takes about 60 seconds to update 10 extensions with the advantage of being able to choose what you want updated (adding automatic functions would be simple...personally I don't like them) . I don't think this script could get much simpler....I included a gui

[jpeters]

Added option "update -f APP" (eg "update -f gnumeric).  Checks individual extension. As always, include
only base name, since script will check tce dir for appropriate file.  "update -d APP" checks deps, and "update -c" checks entire /tce dir .    Update script updates and checks all extensions (tce/tcz).  To update: "update APP" (eg., "update gnumeric") or  "update -g" for gui.  Help: "update --help"

note: very simple & safe; no automatic deleting/installing; tcz unmounted before update; works without rebooting.

Edit: Save script as "update" and place in $PATH (or graphics won't work).  

[jpeters]

edit:  removed extra "/" in 'update -d'  tcedir path.  (crept in after using /mirror/  )
edit2:  more specific find function in "update -f"  
edit3:  reset background after update (necessary for tc_2.1 )

[jpeters]

added wbar.sh to reset wbar at end of script.   Needed with with tc_2.1    

note: sometimes it's necessary to run wbar.sh several times, or you can restart X (alt backspace;startx) to fix the wbar issue. This same issue now appears when loading local extensions.

edit:  fixed   

[jpeters]

Fix so that compiletc, etc, updates (was going to help menu..needed better grep command).

edit: wbar issue occurs only when wbar covered with another window when updating (using jwm)

[jpeters]

...Included a better dependency search (eg "update -d APP")  that reads the dep file, but matches the extensions to those (if present)  in the TCE dir.  I found this useful in checking for missing or corrupted dependencies, in addition to finding those that need updating.  

[jpeters]

added "update -i {tcz,tce} ".   Downloads md5.txt files to /tmp/db-md5 and lists extensions in
Dialogue for new install.  ( note: database can be copied for fast installs).
edit: Set path to persistent database at top of script.  
edit: Fixed bug in "update -c"    (extra char just in this version).
edit: Fix wbar only if using.
edit: Put controls around main wbar code (for those like myself who no longer use wbar).

[jpeters]

Updated for Tinycore_2.3

[jpeters]

Added update support for tcz to ram. Checks for file in tcz2ram.lst, and installs to ram if present. (ex  "update aalib")  

note: script uses wget.tcz  (for update -i )

[jpeters]

New option: "update -ix {tce/tcz}"  : Quickly loads existing database for new install
Use "update -i {tce/tcz}" for building new or adding to existing database (set path
at top of script).  Installs new database at /tmp/db-md5)

uses wget.tcz extension ( uses noclobber option for adding to existing database)