gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: installation domains


From: Nicola Pero
Subject: Re: installation domains
Date: Wed, 29 Oct 2008 21:32:17 +0000


Tentative policy and development proposals ...

Thanks - here is the tentative policy I was thinking of (we can presumably merge the two in some way to move forward) from
the suggestions that have been put forward --

1. we install by default gnustep-make (and hence, GNUstep) into /usr/ local/GNUstep instead of /usr/GNUstep. To avoid breaking things too much, we could detect if there is already an installation in /usr/GNUstep and in that case print a big warning and explain that you need to use --prefix=/usr/GNUstep to get the old behaviour.

2. we add an option to gnustep-make's ./configure to install gnustep- config, openapp and opentool in a different directory
(if nothing's specified, we install them into SYSTEM_TOOLS as we do now)

3. we change gnustep-make's configure to print out some useful message on the chosen filesystem layout (and how to use it)
at the end

4. we add support in gnustep-make for a new variable, something like GNUSTEP_CORE_PACKAGE=YES, which
causes it to install into System by default, instead of Local

5. we add a new option to gnustep-make's ./configure, something like ./ configure --install-core-packages-into=local, which can be used to change where stuff with GNUSTEP_CORE_PACKAGE=YES is installed by default. We default to System but suggest that packagers packaging gnustep-make change it to default to Local instead when shipping
gnustep-make

6. we do a gnustep-make release, then wait 6 months or so, then we change all GNUmakefiles in devmodules that currently have GNUSTEP_INSTALLATION_DOMAIN=SYSTEM to instead have GNUSTEP_CORE_PACKAGE=YES

The only real visible change for people compiling everything from source would be 1., from /usr/GNUstep to /usr/local/GNUstep, but the new ./configure options would allow packagers to ship a better setup.

Your tentative policy is much more aggressive ... in that it suggests moving to FHS by default. I don't really have an opinion on that - I'm happy to do it, but I'm also happy to keep our current GNUstep layout. I think FHS will appeal to GNU/Linux users, and the GNUstep layout will appeal to users from the Apple world. Not sure who would be compiling from source the most. ;-)

More suggestions/comments welcome.

Thanks


please enhance and then we can see if we can agree on the way forward.

1. We will move to FHS as the default layout for new installations

2. We will retain backward compatibility for existing installations (at least for a year or two)

To maintain backward compatibility, the current 'system' applications will need to remain as such when installed into an existing system.

That means they need to carry on to have GNUSTEP_INSTALLATION_DOMAIN defined as SYSTEM in their makefiles (or be changed to use another name, but if we do that we need to synchronise the change with a gnustep-make change, so it's probably easier to leave them unchanged).

3. gnustep-make needs to be changed to:
a. continue to honor GNUSTEP_INSTALLATION_DOMAIN in the makefiles if it is installing on an existing system using old-style locations. b. ignore GNUSTEP_INSTALLATION_DOMAIN in makefiles if it is installing into a new system or a system already using a non-gnustep style layout.

4. gnustep-make should probably also warn about the consequences of the layout selected

5. documentation should be updated to use FHS style layout in all examples.

Does that cover it?


_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev





reply via email to

[Prev in Thread] Current Thread [Next in Thread]