Thanks. This information is important in understanding and using pacman. Perhaps some of these points could be added to the the Package Manager page in WIKI.
I noticed discussion starting on apps having to check J version etc. Perhaps it would be appropriate to have pacman check that. Warn at install time if it was not designed to work on that installation. On Mon, Jun 7, 2010 at 8:53 AM, Sherlock, Ric <[email protected]>wrote: > > From: Don Guinn > > Sent: Tuesday, 8 June 2010 00:12 > > > > Sounds like this is getting away from beta issues and into maintenance > > issues and perhaps the discussion should be moved General as this > > concerns > > anyone using pacman (or JAL) beyond clicking the Package Manager button > > off > > the Run menu. And I got what I deserved for blindly running something > > copied > > from a forum message without understanding what it did. > > Not really. IMO this was a beta-related issue. > As Bill points out the files in the zip that you downloaded from the wiki > work fine with the latest JAL-released version of gui/gtkide. However, > although it has the same version number, the "released" version of the J7 > base library on JAL is not yet compatible with the gui/gtkide. I'm sure this > was not intended and your bug report was valid and useful. > > The reason that upgrading rather than installing "worked" is that 'upgrade' > will only download and install a package if the version number of the JAL > package (in this case the J7 base library) is higher than that currently > installed locally. > > > I had assumed that JAL worked like IBM's SMP and I thought it did > > requisite > > checking. Apparently it does not. And I had avoided studying JAL > > because I > > thought it was like SMP, one of the most boring tools I ever had to > > use. So > > I started reading about JAL this morning. > > > > The distinction between (re)install and upgrade. To what level does > > install > > go? Is it the original (version 0) level or does it install to the > > latest? > > Why is there even an upgrade option? Shouldn't reinstall imply upgrade? > > 'install' will install the latest JAL package over the top of the locally > installed package whether or not it is newer or previously installed. > 'upgrade' will only install a JAL package if the addon has been previously > installed locally and is a later version than the one installed locally. > > > Apparently there are conflicts between base and gtk. Same script files > > included in both, but not the same. Not good. Here is where requisite > > checking is really needed. > > > > In the beta the base directory does not have the same meaning as "base" > > does > > for JAL. For JAL, base means that which is needed to run the > > development > > system. The base directory in the beta is projects for us to play with. > > Which includes stuff not in JAL base. > > I think the base directory in the beta is the (dated) source for the JAL > base library package. As you suggest it contains examples of projects that > beta testers may find useful. However the base/gtk and base/ide folders are > no longer currently found in latest source for the J7 base library: > http://www.jsoftware.com/trac/base7/browser/trunk > > They are now the Addons gui/gtk and gui/gtkide found here: > http://www.jsoftware.com/trac/addons/browser/trunk/gui > > > > I think that the distinction between what is needed to run the > > development > > system and gtk is blurring. Maybe non-existent. Why is gtk and gtkide > > not > > part of system or JAL base? Or will they be merged in when J7 leaves > > beta? > > My understanding is that ~system and JAL base library are the same thing. > In other words, installing a later version of the base library from JAL will > potentially replace anything/everything in the ~system directory tree. > > One of the main ideas behind J7 is that as much as possible will be moved > out of the base library and into Addons. The simplest system possible will > ship with just the jconsole front end, and probably the JHS (browser) front > end. > > The reasoning is that not all users/developers need or want a gui front end > (or many of the other scripts that used to be installed by default). The > other gui front ends - gtkide (and the old C++ front end?) will be > downloadable from JAL as required. > > It is also possible that there will be a number of "ready-to-go" > installation packages that will include some of these addons already. > > On the other hand there are a number of scripts that most people used all > the time (strings, files, dll ...) these have been merged into the stdlib so > that they are loaded by default when you start J. This means for example > that you will no longer need to: > require 'strings files' > > > I had forgotten that the base directory in the beta was for us to play > > with > > build etc. Bill told me that I didn't need to put those scripts from > > the > > latest build into base. I am not sure that is correct. If I were to do > > a > > build from the base directory I think that I would have replaced those > > updated scripts with old ones had I not updated those scripts in base > > as > > well. > > I haven't delved into this. You could be right - Chris will be the best > person to answer. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
