Hi,
On 2005-03-14 15:01:51 +0000 Stefan Urbanek <[EMAIL PROTECTED]>
wrote:
Hello,
I was thinking about packages and installation in an GNUstep based
environments,
such as Etoile. Basically, there are three different environments:
1. Host OS (Linux, MS-Windows, OS-X, ...)
2. GNUstep runtime environment (guest)
3. GNUstep based system (Live-CD is a prototype of such thing)
For the time being we keep the #3 out. I think that GNUstep by its
nature is a
separate, independend and (kind of) self-sufficient environment on
any host
OS.
This is also my view, and I even wrote this on the wiki. I view
GNUstep has having it's own "namespace". Installing a GNUstep app, in
this light, is more like installing a XPI plugin for Mozilla than
actually installing a new app, at least in what concerns the "native"
package management.
It has mechanisms (interfaces) to interact with the outer world, such
as D&D,
filesystem, networking, ports,... Installing and uninstalling gnustep
should
be
as easy as unpacking/removing a directory plus running few
configuration/cleanup scripts.
Indeed. The GNUstep environment proper can also be installed using a
native package method (rpm, deb or tar.gz, as you suggested). But
after having the backbone installed GNUstep should be able to take
care of it by itself.
By default, everything that uses GNUstep is part of the environment
and can
not
be separated (*). That means that MyApp.app is a part of the
environment, and
it should be obvious that it can be used only from GNUstep (**). Any
application, framework or a bundle can be considered as a GNUstep
environment
module. Yes, it is an application, but it plugs inside the GNUstep
and can not
live without it. The applications/frameworks/bundles make the
integrated
environment - they are integral cooperating parts.
Exactly, hence my XPI alegory above.
Some extreme analogies, where left side is GNUstep and right side is
application/framework/bundle:
Java - Java applications
MS Office (Word, Excel) - Visual basic applications/macros
Oracle DB suite - enterprise applications provided by Oracle
and many others you can think of. The right part can not live without
the left
part.
Now let us go to the packages. We have:
- Host OS packages (deb, rpm, tar.gz, Install.EXE, ...)
- GNUstep packages (no standard format defined yet)
As you probably know I'm targeting OS X compatible format, i.e. NeXT
format with some additions and serialized Info and Description files.
This is however no obstacle to further enhacement since the format can
be heavily extended while still remaining compatible (extra keys and
files in a package cause no harm).
We need to distinguish between them and handle them separately if
possible.
That
means that we get following package management applications:
1. manage host os packages
2. manage gnustep environment packages
3. manage host os packages and gnustep environment packages
4. manage gnustep system packages
We do not have to care about the #1 packager. #2 packages should be
available
everywhere where GNUstep environment is installed - on MS Windows,
Linux,
OS-X.
It should handle ONLY gnustep packages. #3 should not be a priority
and should
be offered as option to the GNUstep likers to manage all their
packages on
their system. The #4 is like #3, but is native to its system.
This exactly were may priorities are. I started to focus on the .deb
bundle initially (so #1 and #4 in your list) but with time I drifted
and focused on providing an installer for the GNUstep namespace,
independent of the native os packaging system. It can be extended to
deal with them, but my first milestone is to be able to install (and
optionally uninstall) packages that conform to #2.
This was my point of view to environments and packages. How do you
see it and
how do you think it should be handled in Etoile?
There was some feedback on -discuss when I posted my Installer
message. There were many ideas, the most original of which was the
.pkg/.app hybrid (cehck the mailing list).
I'm open to suggestions in how to extend and improve things, but I
think it's important at this point for me to have a clear and above
all doable goal before trying to extend it to far. This means that I
would really like to finish "basic" .pkg support, meaning the ability
to create packages, to install them, and, since it it's easy after the
previous goals are reached, to convert them between OSX and GNUstep.
This will at least provide something usable, and from there adding
features will be easier.
Best regards,
fsmunoz