[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Symlinks from Tools to Applications
From: |
Richard Frith-Macdonald |
Subject: |
Re: Symlinks from Tools to Applications |
Date: |
Tue, 20 Feb 2007 07:28:13 +0000 |
On 20 Feb 2007, at 02:38, Christopher Armstrong wrote:
Hi
Richard Frith-Macdonald wrote:
I had spotted that one, but was hoping that a more in depth study
would show up a way to work around it.
Another issue is that it doesn't support automated download of
dependencies as far as I can see, and the declarative nature of
the package files makes it hard to see how adding a dependency
download mechanism could be done cleanly.
The WiX idea of tagging everything independently to allow upgrade
of each bit separately is pretty attractive, but I think a better
solution for GNUstep is to have smaller packages able to download
dependencies automatically. The first format is simpler for
distribution on cd-rom, but I don't think that's what we are
aiming at.
Perhaps we should devise an installer that can download, install
and upgrade various components as needed.
Yes, I think that's the best way to manage things.
On Windows these fall into roughly these categories:
1. GNU (essentially binaries for stuff like libtiff, jpeglib,
libxml2, libiconv, libintl etc). Could perhaps share with gtk, but
probably best to keep our own copy to avoid DLL Hell issues.
2. GNUstep runtime (objc runtime, base, gui, and back + assorted
utilities, file system layout and tools)
3. MSYS and some extra utilities
Yes, probably ssh and svn at least.
4. MinGW compiler(s) and headers (gcc-core, gcc-g++, gcc-objc,
w32api etc)
5. GNUstep Development (headers and libraries, ffcall, etc).
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 :-(
Re: Symlinks from Tools to Applications, Ingolf Jandt, 2007/02/23
Re: Symlinks from Tools to Applications, Gregory John Casamento, 2007/02/17
Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/17
- Re: Symlinks from Tools to Applications, Richard Frith-Macdonald, 2007/02/18
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/19
- Re: Symlinks from Tools to Applications, Richard Frith-Macdonald, 2007/02/19
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/19
- Re: Symlinks from Tools to Applications,
Richard Frith-Macdonald <=
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/20
- Re: Symlinks from Tools to Applications, Christopher Armstrong, 2007/02/26
Re: Symlinks from Tools to Applications, Nicola Pero, 2007/02/17