Re: Symlinks from Tools to Applications

[Christopher Armstrong]

Hi

NSIS is really nothing more than a stack based programming language. It 
just happens to have a rich set of modules for assembling an installer 
and a very good supporting community. Package "Management" can certainly 
be contained considering a number of issues:

1. Mingw, MSYS and the GNU libraries don't change often enough to break 
binary compatibility between versions very easily. It is reasonable to 
treat any version of these as "stable" and good enough for long-term use 
without upgrading all the time.

2. One of the key issues is binary compatibility between applications 
and tools, and the gnustep libraries. This does seem to change between 
versions, so we will need some versioning information to be stored with 
"packages" for download, including a minimum base/gui combination for an 
application binary. Frameworks would seem to be a partial answer to this 
issue, but only if applications or tools are linked against the right 
version of a framework and that framework version is correctly loaded 
when an application or tool is loaded.

Another possible solution is to allow dll versions to be embedded in the 
name of the dll on Windows (currently we have gnustep-base.dll and 
gnustep-gui.dll). We could at least have only a major number embedded in 
the name of these (such as gnustep-gui1.dll for 1.0 and gnustep-gui2.dll 
for unstable versions, etc).

Windows XP also allows the embedding of "manifest" files, which allow an 
application to specify the version of libraries that it is linked 
against, such that Windows tries to load up the correct version of a 
library when faced with an incorrect version. I'm not sure how this 
works exactly, but could be a useful solution.

The most inefficient solution in this case may end up being the simplest 
and least hassle; we simply just uninstall all application binaries when 
the GNUstep libraries change binary compatibility. For the time being 
though, I think this issue is best left unsolved as we just want an 
installer first that knows when it can upgrade software. We should just 
tell the user that if they are upgrading GNUstep they should upgrade 
their programs.

On that note, if a class's binary compatibility changes, is there a 
programmatic way for a program to find out that its loaded a library 
with an incompatible class version and inform the user that the program 
needs to be recompiled or upgraded? I know Objective-C classes support 
versions, but its not clear how this works. Also, if applications don't 
access the instance variables of a class, this would certainly improve 
their binary compatibility as they wouldn't care about the internal 
layout of the class?

3. Most of these tools we would be trying to provide as a basis for 
developers to create and bundle applications for Windows as just one 
target platform, albeit an important one. To a certain extent, packages 
could just be limited to installing the GNUstep libraries.

In all, I think we will end up having to write much of this ourselves, 
as no real Windows solutions exist. As attractive as WiX is for this 
issue, IMHO it will end up introducing additional problems.

Cheers
Chris

Richard Frith-Macdonald wrote:
> On 20 Feb 2007, at 02:38, Christopher Armstrong wrote:
> > I was thinking an all-in-one installer, that let the user select 
> > between a "user" and "developer" installation. The "user" one would 
> > contain 1 & 2 (possibly 3), the "developer" containing all of them. 
> > The MinGW installer again has a good idea on doing this; we store an 
> > .ini file on our web site and the installer downloads this to get the 
> > locations and names of the packages needed to be extracted on a 
> > user's HD. To make things more flexible, this file should store a 
> > archive name and version so that we can work out what needs to be 
> > upgraded in the event the user already has parts of GNUstep already 
> > installed. How to handle upgrades is a little bit unclear, as we 
> > should remove old files instead of extracting over the top (perhaps 
> > we can store a list of files that was installed with a package?).
>
> 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)
>
> 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.
>
> 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 :-(