Re: installation domains

[Riccardo Mottola]

Hi,

things are starting to delineate and I think there are good ideas 
floating around. I am mainly concerned with the defaults, which I'd 
like to keep as is.

Some comments below.


On 2008-10-29 22:32:17 +0100 Nicola Pero 
<address@hidden> wrote:

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

I think this is essentially useless. /usr/GNUstep is fine for me. 
Those who package or have the knowledge that they want to "fine tune" 
their install, like directly into /, /usr, /usr/local or /opt 
(examples)... will have the knowledge to read the manuals, the wiki, 
whatever.
Those who do not understand, shouldn't even compile: they should (and 
most probably will) pull packages from their distribution and there 
the packager will have done the work.

> 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
as long as it stays by default to SYSTEM, it is fine. THis is actually 
needed for what I write below.

> 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
Yes. as in 4. I tink this is most useful for FHS.

> 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
Thus the result... would be the same.

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

I'd even avoid that change, for the reasons above.

Let me sum up. We have mainly two install scenarios corssed by three 
user scenarios
install:
A: standard GNUstep layout with some kind of prefix (/usr/GNUstep 
being currently the default)
B: FHS layout

usage:
1. packages
2. self compilation of everything
3. self compilation of some applications

A2 is what we currently do. I think "nothing" should change. I expect 
system stuff to go into system, local stuff into local. This mimicks, 
once compiled, that it looks like a supplied OS, say Apple or OpenStep

B2: there i think your new flag about CORE PACKAGE comes handy, before 
your idea I was oging to complain about that: OS-supplied packages co, 
for example, all in /usr and should ignore our "system" and "local" 
distinction. Thus from the packagers point of view SYSTEM and LOCAL 
domain should be the same: if a packager supplies FTP.app it should go 
into the same plabe as GWorkspace.app or SystemPreferences.app. That 
is, usually, /usr/bin

A1, B1: be it A or B, it is at the packagers choice, there should be 
no problem at all, he is capable of passing the flags to configure, 
once documented well

3A, 3B: as long as the user compiles new applications, everything goes 
into the LOCAL domain as expected (for FHS, /usr/local). The scenario 
is that the installs all the core stuff and then, for example, pulls 
FTP.app and decides to install it himself.

there are two problem which are on the border though.

p1. GNUstep doesn't support multiple instances of the same application.
this affects the B (FHS) scenario mostly. A user gets the core stuff 
by packages, everything is into /usr.
He installs FTP from a package. gets into /usr. He now compiles a 
newer FTP from sources, according to FHS logic it should go into 
/usr/local. (this is standard today: on my solaris box I have the 
stanard tar and the gnu tar...) but make_services would complain for a 
double installed app

p2. the developer. He installs everything from source, typically in 
scenario A (that's me...). I want system stuff to be in /System and my 
own stuff into /Local. ANd I should be able to recompile the system 
stuff as many times I want.

problem 2 currently doesn't exist: it just works that way, but I fear 
it could break

problem 1 currenty doesn't exist since everything behaves like 2. I 
don't understand how you can distinguish between package supplied 
stuff and user compiled stuff with a single make-system.
On the other hand I agree with you that if something is in /usr it 
shouldn't be deliberately replaced by the stuff compiled by a user.
So I would accept a compromise where you install a package, compile 
your own version, get an error and need to remove the package.

So, after this long summary, a possibility would be:
Do not change anything significantly. Stuff are good as they are, but 
allow the "merge" of SYSTEM and LOCAL to ease FHS compliancy.

For me this solves about everything except problem 1: it would make a 
user replace system supplied applications.

I don't understand how you can solve p1 easily though. Each package 
should know instead of whether it is compiled for system or local.

so you could add to the make, an option like "PACKAGE_INSTALL=YES" 
which could install into SYSTEM which would be used by the packager. 
and install say FTP.app into /usr instead of /usr/local

what emerges from these thoughts, is that the OpenStep domains /System 
and /Local do not map to the FHS /usr and /usr/local precisely.
Further, we differ from other executables that we can't have two 
versions.

further elaborations? I wrote this in response to your bug report: by 
default I would expect that libobjc or SystemPreferences go into my 
/System.

Riccardo