[Top][All Lists]
[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