Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

Perhaps a little late, although I've had the weekend to think about it.

On Tue, 20 Feb 2007 07:28:13 +0000, "Richard Frith-Macdonald"
<richard@tiptree.demon.co.uk> said:
> That sounds pretty much what I was thinking ... a small installer  
> package which could either
> 1. download and install the runtime environment for a user or
> 2. download and install the full development environment
> and would be capable of checking package versions and upgrading (by  
> uninstalling the old version and installing a new one)

I've been reading into this more and more, and I think a solution
involving both installers may be possible. NSIS is useful for the kind
of stuff like mingw, msys and the GNU dependencies like libiconv,
libtiff etc. where we just need them to be extracted into a directory
and upgraded infrequently. The current Windows installer handles this
case well. We might just extend this paradigm a little further by adding
code to the installer that kept a list of files that was installed with
a component, and used that list to remove the component's files come
upgrade time. Currently I believe these installers just extract a tar.gz
file over the top of old versions and delete the installation directory
upon uninstall.

WiX is more useful for GNUstep itself. It uses GUIDs (those horrible COM
128bit unique identifiers) to identify components in an installation.
Remember WiX has a restriction that forces a component to exist only in
one directory (not subdirectories), which is a limitation inherited from
Microsoft Windows Installer. The various GNUstep build types like
tool.make, application.make, framework.make, bundle.make etc can be
separated out into components within their "wrappers" such as one
component for the main executable and .desktop file, one component for a
set of resources in the Resources directory, and recursively as you deal
with .gorm, .palette, etc inside the Resources directory. Thankfully it
can build "merge modules", which are an installer equivalent of a
C/C++/ObjC .o file. A whole application, e.g., would be distributed as a
package, but as it is compiled, the interface files and resources would
be built up as a set of components built as separate merge modules.
These merge modules would then be referenced and included in the
package. 
 
> Supplemented by a makefile (to be installed like the existing rpm  
> make file) to automate creation of a package for a library/framework/ 
> tool or application.
> Each if these packages would know how to download and install the  
> runtime environment and/or any other packages it needs.

The gnustep-make package would need to be modified so that it can
generate WiX packages and merge modules (via separate commands) for each
type of project. It also needs to be modified so that a file to be
distributed with the sources stores a set of GUIDs (which must remain
constant between project versions) that are read upon each package/merge
module build. I guess this can just be a text file with records
containing a name field and a GUID field. Obviously we want the user to
simply be able to go:

make win32inst-package OR
make win32inst-mergemodule

or the like. Frameworks would want to generate a different set of GUIDs
for each version in the framework, so that different versions can
coexist.

However, if WiX is not to be used, a similar system as proposed for
MingW etc could be autogenerated in the form of .nsi files for GNUstep
related builds. 
> 
> Basically, my ideal is a package management system rather than a  
> simple installer ... and perhaps that's just too ambitious.
> However, I wonder if there is already a tool which could be used to  
> manage the dependency/version tracking part of this.  It looks like  
> NSIS is flexible/powerful enough to let us add that sort of logic,  
> but it's not built in, and it would be nice if we could find an  
> existing system that would integrate well with NSIS, to handle that.
> The only thing I see on the net is winpackman ... and that doesn't  
> look mature/stable :-(

NSIS is scriptable (unlike WiX) and allows third-party dlls to be used,
so we could write whatever code we need for a simplified package
management system (obviously nothing as sophisticated as Debian). My
idea above about storing a list of the installed files would require
that we write an add-on that first recorded the files installed from a
.tgz, and secondly, read back the list of files installed and allowed
the installer script to delete them by name. WiX, however, handles
installation of components anywhere and can identify a person trying to
install the same thing in a different location as it maintains a
component database in the registry using the GUIDs as identifiers.
Uninstallation with WiX is simply a matter of getting it to remove the
components in a package. 

Both WiX and NSIS would advantage from registry entries in a reliable
location that point to the various GNUstep subdirs such as
/System/Applications, /Local/Applications, /System/Library/Frameworks,
etc. Something like GNUstep.conf-dev in registry form generated by
gnustep-make from the FilesystemLayouts stuff.

Regards
Chris

-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au