functions in pkg_mngr.i -

             get_intern_date(date)  
 
   meant to convert date returned by getdate() into something  
   clear and understandable by people from europe and US  

             has_write_permissions(dir)  
 
   Test if user has write permission in "dir"  
   returns 1 if the user has write permission, 0 if not.  
   Create and delete a file "test_permissions_$USER", with  
   $USER = name of the user as defined in this session environment  

             parse_info_file(file)  
 
   Parse a .info file (file describing a package in the  
   yorick package manager, similar to fink/debian info files)  
   Return a structure with elements = parsed keywords values  

             pkg_fetch_url(url,dest,verbose=)  
 
   wrap the url fetch command (e.g. curl) with error checking  

             pkg_get_keyword_value(text,keyw)  
 
   return parsed value of keyword read from a .info  
   file, in the form:  
   keyword: value  
   or  
   keyword: >>  
   multi  
   line value  
   >>  

             pkg_info,pkgname  
 
   Prints out more information about package "pkgname" (string).  
   Does nothing else.  

             pkg_install,pkgname,force=,check=,verbose=  
 
   Install package "pkgname" (string vector)  
   Grabs the tarball from a central server, untar it, copy the files  
   according to the directory structure specified in the untared  
   package, possibly run a preflight and postflight include files (for  
   special needs), and place the package info file and a list of  
   installed files in package/installed/.  
   pkgname can be a string scalar, vector, and contains wildcard to  
   install multiple packages in one call.  
   examples: pkg_install,"y*" or pkg_install,["soy","yao"] or pkg_install,"*"  
     
   Keywords:  
   force: force installation  
   check: run checks after install  
   verbose: 0 (silent), 1 (some messages), 2 (chatty), 3 (more chatty)  
     

             pkg_list,server,sync=,verbose=  
 
   Print out a list of available packages, including  
   version number, whether it is installed (installed  
   version), and a short description.  
   server: overrides the PKG_SERVER variable definition  
   sync= : if set, equivalent to "pkg_sync; pkg_list;"  

             pkg_mngr.i  
 
    
  Yorick Package Manager. Main functions  
    
  pkg_setup               Set up pkg_mngr parameters (see below for details)  
  pkg_sync                Sync the local package repository with server  
  pkg_list                List all available packages (list install status  
                          ("i" marks installed packages), the package name,  
                          the last available version, the installed version  
                          (when applicable) and a short description.  
  pkg_install,"pkg_name"  Install package "pkg_name"  
  pkg_upgrade,"pkg_name"  Upgrade package "pkg_name"  
  pkg_remove,"pkg_name"   Remove package "pkg_name"  
  pkg_info,"pkg_name"     Print detail info about package "pkg_name"  
  pkg_save                Saves PKG global variables in default file,  
                           which will be re-read each time pkg-mngr.i  
                           is included. Called by pkg_setup.  
  pkg_reset               Delete all tarballs (in case of problem).  
    
   --- INTRODUCTION TO THE YORICK PACKAGE INSTALLER  
    
   --- TYPICAL USE  
    
   FIRST TIME USE:  
    
   > pkg_setup  
   ... will ask for parameters for your OS/installation  
   ... just set the OS, most of the other defaults should be OK.  
    
    PKG_FETCH_CMD       : system cmd to fetch a file through an  
                           internet connection [ex: curl]  
    PKG_SERVER          : URL of central server with info files  
    PKG_OS              : OSTYPE-ARCHTYPE. There is a limited number  
                           of these available. pkg_setup will fetch  
                           available value from the server and propose  
                           a list to the user.  
    PKG_GUNTAR_CMD      : system cmd to gunzip and untar a tgz file  
                           [ex; "tar -zxf"]  
    PKG_TMP_DIR         : temporary directory. Normaly Y_HOME/packages/tmp  
    PKG_VERBOSE         : verbose level  
    PKG_ASK_CONFIRM     : ask for confirmation in critical operations  
    PKG_RUN_CHECK       : run check after install  
    
   > pkg_sync  
   ...to sync your local info file repository with the server  
   ...this should be done from time to time.  
    
   ---  
    
   > pkg_list  
   ...fetch all packages .info files on the server, and prints out  
   the available & installed packages, with their version.  
    
   > pkg_install,"pkgname"  
   ... will install package "pkgname"  
    
   FURTHER USE:  
  pkg_list, pkg_install, and pkg_remove are the only 3 functions  
  that should be necessary for further use.  
    
   --- IN CASE OF PROBLEMS:  
   In case something went wrong and you downloaded a bad tarball:  
   Solution 1: try reloading with force=1  
   Solution 2: Go in Y_HOME/packages/tarballs  
   and remove the offensive tgz file. In doubt, you can just wipe  
   up the whole directory content. tarballs will be downloaded again  
   if pkg_mngr does not find existing local ones.  
    
   --- SERVER / CLIENT ORGANIZATION  
    
   The yorick package manager (pkg_mngr.i) is organized with several  
   central servers (sourceforge, maumae), being repositories of binary  
   packages. These packages are self-contained plugins for yorick, and  
   include yorick include files, autoload files and libraries. Necessary  
   dependencies have been linked in. Other yorick package dependecies  
   are cared for, and dependent packages are installed automatically.  
    
   Locally, the directory package is the home of the packager. It contains  
   3 subdirectories:  
   packages/info: home of the info files that describe all available  
                  packages.  
   packages/installed: info files for installed packages.  
   packages/tarballs:  tarballs for installed packages.  
    
   --- PACKAGE STRUCTURE:  
    
   A standard package includes (once tar zxvf'd):  
    
    
   root/  
   root/pkg.info         : package info file  
   root/preflight.i      : if present, will be run, from Y_HOME/packages,  
                            before the copying of the other files (but  
                            after the tar -zxvf or equivalent).  
   root/postflight.i     : if present, will be run, from Y_HOME/packages,  
                            after the copying of the other files (but  
                            before the dist tree cleanup).  
   root/dist/            : distribution root  
   root/dist/y_site/     : all the files under this will be copied  
                            recursively into Y_SITE.  
   root/dist/y_home/     : all the files under this will be copied  
                            recursively into Y_HOME.  
    
   I recommend to include and distribute a copy of the package source:  
   It is (1) educational, (2) easier to rebuild if needed and (3) that's  
   a good place to store a check.i and other example for the package (and  
   perhaps a doc). A good place to store the source is Y_SITE/contrib/pkg.  
    
   Here is an example for the HDF5 package:  
     
   poliahu:tarballs% tar zxvf hdf5-0.5.tgz  
   hdf5/  
   hdf5/dist/  
   hdf5/dist/check.i  
   hdf5/dist/y_home/  
   hdf5/dist/y_home/i-start/  
   hdf5/dist/y_home/i-start/yhdf5.i  
   hdf5/dist/y_home/lib/  
   hdf5/dist/y_home/lib/hdf5.so  
   hdf5/dist/y_site/  
   hdf5/dist/y_site/contrib/  
   hdf5/dist/y_site/contrib/hdf5/  
   hdf5/dist/y_site/contrib/hdf5/check.i  
   hdf5/dist/y_site/contrib/hdf5/hdf5.c  
   hdf5/dist/y_site/contrib/hdf5/hdf5.i  
   hdf5/dist/y_site/contrib/hdf5/Makefile  
   hdf5/dist/y_site/contrib/hdf5/yhdf5.i  
   hdf5/dist/y_site/i0/  
   hdf5/dist/y_site/i0/hdf5.i  
   hdf5/hdf5.info            
    
   --- INSTALLER MECHANICS  
    
   The operation of installing a packages goes through two main parts:  
    
   part 1. Get the tarball from the server.  
    
   part 2. Once the tarball is local, it is installed. All the libraries  
     and other files are put where they belong. Usually:  
     libraries (*.so) are put in Y_HOME/lib  
     include files (*.i) are put in Y_SITE/i0  
     autoload files are put in Y_HOME/i-start  
     However, this is not mandatory, and depends on how the maintainer  
     has arrange the files in the tarball.  
     The installer also scans for a preflight and postflight include files,  
     and run them (include them) if present.  
    
   In more details:  
    
   pkgname example = hdf5;  
    
   I.  check for depenency tree. Announce dependencies, possibly  
       ask for confirm.  
   II. Start by lowest dependency:  
      1.  check if already on disk locally [to come]  
      2.  if yes, check that local version is the last one [to come]  
      3.  if not, offer the choice to re-install local version  
            or fetch and install new one [to come]  
      4.  fetch tarball (if necessary)  
      5.  md5 it [to come]  
      6.  gunzip + untar it (e.g. tar -zxvf)  
      7.  cd in pkgname directory  
      8.  check if preflight exist. If it does, execute it (include it).  
      9.  recursively copy the distributed files in Y_SITE and Y_HOME  
      10. copy the info file in the installed directory, with a list  
            of the installed files.  
      11. check if postflight exist. If it does, execute it (include it).  
      12. clean up after ourselves (temp dist tree). Keep tarball.  
              
   III. Update installed pkg. This is done automatically by putting  
        the info file of the installed package in package/installed  
    
    
   --- .INFO FILE  
    
   Here is an example of a .info file (from the hdf5 package):  
    
   Package: hdf5  
   Kind: plugin  
   Version: 0.5  
   Revision: 1  
   Description: Hierarchical Data Format 5 interface  
   License: GPL  
   Maintainer: Francois Rigaut   
   OS: macosx  
   Depends: yorick(>=1.6.02)  
   Source: http://www.maumae.net/yorick/packages/%o/tarballs/hdf5-%v.tgz  
   Source-MD5: 6f8038cd09f72f4ff060e2d278256b6f  
   Source-Directory: contrib/hdf5  
   DocFiles: README NEWS doc/*.doc doc/*.pdf doc/*.ps doc/*.tex  
   Homepage: http://www.maumae.net/yorick/doc/plugins.php  
   DescDetail: <<  
   HDF5 is the yorick interface plugin to the NCSA Hierarchical Data Format  
   version 5. It includes function for reading, writing, updating, getting  
   information on HDF5 files.  
   <<  
   DescUsage: <<  
   See i/hdf5_tests.i for a test suite. Type   
   "yorick -batch hdf5_tests.i" in a terminal to run it.  
   <<  
   DescPort: <<  
   This package will compile Yorick only on MacOSX 10.3.4 or later, because  
   of a bug in the system math library libm (part of /usr/lib/LibSystem.dylib)  
   in earlier versions of MacOSX 10.3.  
   <<  
    
   Right now, the only important (used) keywords are:  
   Version, Description, OS, Depends, Source  
    
   If you want to contribute a package, you will have to generate a  
   .info file:  
    
   Instructions and tips:  
   - Keep the description short (< 45 characters), you can expand ad lib in  
     the DescDetail  
   - Depends can include several members, separated by a comma (e.g.  
     yorick(>=1.6.02),imutil(>0.4)  
   - OS has to be "macosx","linux" or "windows" for now. lowercase pls.  
   - Source if the URL where the tarball can be fetched. In the near future,  
     I'm planning to make that compatible with a vector (several URL that  
     will be tried after another in case a link is down) but for now,  
     keep that a single URL.  
   - Version can only contain integer (e.g. 2.1.4-r2 does *not* work).  
     
    
   --- HISTORY  
    
   * v. 0.7, Sun, 21 May 2006 19:00:55 +0200  
     Francois Rigaut & Thibaut Paumard  
     Allow installations in other locations than the Y_SITE and Y_HOME.  
     Some users may not have access to these and still want to install  
     packages for their personnal use.  
    
   --- TO DO  
    
   * Check documentation relative to new functionalities in v. 0.7  
    
   * At one point, we should have, to complement this installer, a   
     utility to check for symbols conflicts (e.g. same function names  
     in 2 different packages)  
    

             pkg_remove,pkgname,verbose=  
 
   Remove package "pkgname" (string)  
   Remove all files (libraries, include files, autoload)  
   that were installed by the installer.  
   pkgname can be a string scalar, vector, and contains wildcard to  
   remove multiple packages in one call.  
   examples: pkg_remove,"y*" or pkg_remove,["soy","yao"] or pkg_remove,"*"  
     
   help,pkg_mngr for more details.  
     

             pkg_reset(verbose=)  
 
   Brute force solution: if a bad tarball has been downloaded,  
   pkg_mngr will try and try using it and fail. One can remove  
   it by hand in Y_HOME/packages/tarballs/ or use this routine  
   to remove them all.  

             pkg_save  
 
   Save the packager parameters in the file  
   Y_HOME/packages/pkg_setup.i  

             pkg_setup  
 
   Simply print out the global variables relative to this  
   package manager.  

             pkg_sync(server)  
 
   sync the info tree with the central server  
   server: overrides the PKG_SERVER variable definition  

             pkg_sys(cmd,verbose=)  
 
   simple interface to the system command.  
   Allows echoing of commands output to system  

             pkg_upgrade,pkgnames,verbose=  
 
   Upgrade requested packages, or all upgradable packages if no arguments  
   Upgrade to highest available version.  
     
   pkg_upgrade,packages  
   pkgname can be a string scalar, vector, and contains wildcard to  
   install multiple packages in one call.  
     
   examples: pkg_upgrade,"y*" or pkg_upgrade,["soy","yao"] or pkg_upgrade,"*"  
   Without arguments, upgrade all upgradable packages.  
     
   bug: I don't correctly parse the version, so 0.5.03 is considered  
   lower than 0.5.2  

 pkginfo_str{  
 
struct pkginfo_str{  
  string name;  
  string kind;  
  string vers;  
  string revision;  
  string desc;  
  string license;  
  string maintainer;  
  string os;  
  string depends;  
  string depends_pkg(20);  
  string depends_vers(20);  
  string depends_rel(20);  
  string source;  
  string md5;  
  string dir;  
  string docs;  
  string homepage;  
  string desc_details;  
  long   version(20);  
};  

             recursive_rename,dir1,dir2,&list,verbose=,init=  
 
   As it says. This routine will move the whole content of  
   dir1 to dir2, recursively.  
   Absolute equivalent to the linux/unix command  
   cp -pr dir1 dir1  
   Except that the files get moved, not copied.  

             recursive_rmdir,dir,verbose=  
 
   Recursively delete all files and directories under dir, dir  
   included.  
   Equivalent to the linux/unix command  
   rm -rf dir  
   Note that recursive_rmdir,"." will fail removing "." (for  
   some reason).  

             vers_cmp(v1,op,v2)  
 
   Compare (software) version, using operator op.  
   Returns 0 (fail) or 1 (pass).  
   Operators allowed are >=, >, ==, < and <=  
   Will possibly fails for subversion # > 99 (will exit in error if  
   case arises)