Hi Stefan,
I gave this some thought:
Anyway, the main idea behind my first post was not package management
system, but how packages are packaged and what they contain. So, if
GNUstep picks this or that package manager it is ok as far as it uses
larger package granularity.
Besides technical things in package management, it should take into
account 'cosmetic' part of it. This is important for ordinary end
users as they usualy do not want (and they are not going to learn)
all those cryptic package names, version, dependencies stuff or other
things. To sum up package management from user's point of view:
- use larger packages containing whole parts/suites of the GNUstep
system/environment
- use descriptive names with nothing but simple version attached
(System-1.0.deb, Developer-1.2.rpm)
- minimalise dependencies
- (what else?)
The else for me is let's make the install from source easier first.
Building from source for most GNUstep packages takes very (suprising
little) time. So I was thinking of the following:
1) The make wrapper decides on the use of ./configure
2) When build is done a Version file is created in a generic directory
e.g. System/Library/Sources/Installed/gnustep-base/
(preserve settings if username/password are set)
3) According to rules in Makefiles/Master/rules.make
When update is requested the Version file is read and based on the
installed version a cvs/unstable/stable update is done.
When update-unstable is requested the latest unstable version is
downloaded
When update-cvs is requested the lastest cvs version is downloaded
When update-stable is requested the lastes stable version is
downloaded
4) a normal make can be run in the directory
Other possible options:
5) sync-cvs sends changes to cvs (note the programmer has to change
username
and password in the generic Version file)
6) send-patch send a diff to the PATCH_EMAIL address
Issues:
What are the commands on e.g. Windows/Linux/AIX/Whatever
solution: a cvs Tool and a wget Tool written in Objective-C
and part of gnustep-make
Bootstrapping GNUstep
solution: gnustep-make contains an initial database with
Version
files for gnustep-base, gnustep-gui, and gnustep-back
Other option is using the make wrapper to bootstrap -make -base
-gui and -back
Attached you'll find an example make-wrapper and Version file.
Note they are examples :)
It's for GNUstep users, developers can use sources and customise
their system (Virtual/Faked packages? ... shuold be, but it is going
to be more complicated than necessary).
Keep it simple and easy to use,
As for the packages I would suggest to just make a tar.gz from the
installed files (like I did for Ocean). One can always extend on the
database and scripts/programs around it. But it keeps the packages
simple (and I don't need to repackage them when I change something in
the database).
I am a bit worried about the minimalize dependencies. How do you want
to accomplish that? Let's give an example that illustrates my point:
Package A needs lib B, package C needs lib B. To minimize dependencies
you'd want both packages to have lib B, but which version are you
going to support. Because both lib B's have the same version but one
is compiled with D support and the other lib B is compiled with E
support...
Dependencies are not funny ;) I am currently thinking of putting e.g.
libsmbclient into something like Frameworks/SMBKit.framework/Libraries
so that I know this is not an issue. And to adjust libSMBKit to use
that one (thus using hardcoded paths, or something like that).