Re: Package management

[Dennis Leeuw]

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).

Happy Stepping,

Dennis Leeuw

# This file is included in various Makefile's to get version information.
# Compatible with Bourne shell syntax, so it can included there too.

# The version number of this release.

PACKAGE_NEEDS_CONFIGURE=YES

PACKAGE_TYPE=gnustep         # Can be: gnustep|posix|windows|macosx
PACKAGE_NAME=gnustep-base
PATCH_EMAIL=gnustep-dev@gnu.org
PATCH_DIFF="-n -u"

# Version number descriptions
STABLE_VERSION_MAJOR=1
STABLE_VERSION_MINOR=8
STABLE_VERSION_VERSION=0

UNSTABLE_MAJOR_VERSION=1
UNSTABLE_MINOR_VERSION=9
UNSTABLE_BUG_VERSION=1

VERSION_INSTALLED=STABLE
VERSION=$STABLE_VERSION_MAJOR.$STABLE_VERSION_MINOR.$STABLE_VERSION_BUG

# Source descriptions
SOURCE_CVS_HOST=cvs.host.com
SOURCE_CVS_DIR=/path/to/
SOURCE_CVS_MODULE_NAME=base
SOURCE_CVS_USER=
SOURCE_CVS_PASS=

SOURCE_UNSTABLE_HOST=ftp.host.com
SOURCE_UNSTABLE_DIR=/path/to/
SOURCE_UNSTABLE_NAME=file
SOURCE_UNSTABLE_USER=anonymous
SOURCE_UNSTABLE_PASS=anonymous@domain.com

SOURCE_STABLE_HOST=www.host.com
SOURCE_STABLE_DIR=/path/to/
SOURCE_STABLE_NAME=file
SOURCE_STABLE_USER=anonymous
SOURCE_STABLE_PASS=anonymous@domain.com

#!/bin/sh

if [ "x$GNUSTEP_ROOT" = "x" ]; then
        echo "Please source GNUstep.sh first"
        exit 1
fi

# Get data
. ${PWD}/Version

REAL_MAKE=/usr/bin/make

if [ "x$1" = "x" ]; then
        if [ "x$PACKAGE_NEEDS_CONFIGURE" = "xYES" ]; then
                echo "Running configure"
                ./configure && $REAL_MAKE
        fi
else
        $REAL_MAKE $@
fi