One other thing,
I've decided not to use RPM for package management, it's kinda a pain to=20=
use. Either we can make our own simple package system or use someone=20
My own idea was to use simple tarballs with a layout like so:
/pre-install.sh #executed before contents.tar.bz2 are untarred =
/post-install.sh # executed after contents.tar.bz2 are =
untarred (in /)
/DEPENDS #a list of packages which need to installed =
first (see below)
/VERSION #a simple text file having the version number =
the file could be renamed and is not always accurate)
/contents.tar.bz2 #the contents of the package to untarred in /
Packages can be named as follows:
for example GNUstepBase-1.3.2-i586.sgstep
The pre/post/upgrade/install scripts will do whatever the package=20
maintainer wants, for instance, the pre-upgrade.sh can save user defined=20=
settings (like in /etc), then contents.tar.gz is untarred, then=20
post-upgrade.sh puts the originals back
the DEPENDS file is a simple list of packages needed and their MAJOR and=20=
MINOR numbers. the packages must have a higher release version than=20
what is needed (unless the user has a higher MAJOR version installed)
For example, the DEPENDS for GNUstepGUI-0.7.7 could be:
for example, if the user has glib-2.30 package installed, everything=20
would be ok. However, if the user had (lets say) glib-3.0.0 installed,=20=
the package could not be installed, since a higher major version often=20=
times means binary incompatibility.
after a package is installed, a directory system will track it in=20
/var/package. For emaple, there would be a directrory=20
/var/packages/GNUstepBase and in that directory would be the VERSION=20
file, the DEPENDS file, and a listing of the files it installed and=20
their locations (very simple to create from the contents.tar.gz file).
Packages should definitely be split into USER and DEVELOPER. I think=20=
that for a distro like SimplyGNUstep (or whatever it may eventually be=20=
called) should default to only istalling USER packages. No need to=20
confse normal users with /include and .a static libs
IF ANYBODY KNOWS OF A *WORKING* PACKAGE MANAGER SIMILAR TO THIS PLEASE=20=
EMAIL ME, IT WOULD BE SHAME TO REPRODUCE EXISTING WORK.
Being and old slackware user, I know that the slackware packages are=20
similar. I remember that it didn't handle dependencies very well (or at=20=
all). Perhaps it has improved since then and we can use the slackware=20=
package system, if anybody knows if that's possible, please email me=20
about that as well.
On Wednesday, May 29, 2002, at 01:04 PM, Rafael de Jaime Juli=E1 wrote:
> Dear Eugenia,
> I have been reading the report about SimplyGNUstep (SGS) on OSNews, =
> unfortunately, I find it a little bit incomplete and confusing. I hope=20=
> you can include this in the website. Please feel free to correct any=20=
> grammar errors you may find. I am a collaborator to the project, and I=20=
> hope i can make clear our goals.
> What is SimplyGNUstep and what will it become.
> SimplyGNUstep has in very little time become relatively very popular.=20=
> This is the naked truth about it.
> #1: SimplyGNUstep is an OS. SimplyGNUstep is not a 'funny' linux =
> Just like nobody dares to say Mac OS X is a 'funny' BSD distribution,=20=
> SimplyGNUstep aims to be a full OS. It will be, of course, Linux =
> for several reasons. The first and most important is that the platform=20=
> in which GNUstep is more stable is Linux. That would be enough by=20
> itself, especially considering that it is VERY unstable in other=20
> platforms. Nonetheless, there's more to it. Using Linux, we can make=20=
> sure that SimplyGNUstep will run in a very wide range of hardware=20
> #2: SimplyGNUstep is not simply GNUstep.
> The Live CD we all (or many of us) know was not SimplyGNUstep, but =
> a sample, a sketch, a prototype of the future. First of all,=20
> WindowMaker will not be the window manager for SimplyGNUstep. We =
> to use InterfaceWM, that is entirely written in Objective-C and will=20=
> allow a lot more system integration. Besides GNUstep apps,=20
> SimplyGNUstep will run normal Linux apps (even though none are to be=20=
> bundled in the distribution, except, probably, Mozilla). Also, a =
> compatibility layer called Graphite is expected to be included in=20
> version 1.0.
> Our intention is to provide a finished system, just like Mac OS X.=20
> Thus, we will not bundle OpenOffice or KOffice, or Gnumeric, or any=20
> other non-essential application. But the ones bundled will not be=20
> trivial. A Terminal, GNUMail, an iTunes-like app, an Address Book, a=20=
> Calculator, a Network Utility, a System Preferences... A desktop=20
> manager called Workspace will be developed, attempting not to clone =
> to surpass Apple's Finder... As you see, there's a lot of work to do.=20=
> We only have the APIs, now we need the OS.
> Thanks for your time,