[Top][All Lists]

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

Re: installation domains

From: Riccardo Mottola
Subject: Re: installation domains
Date: Thu, 30 Oct 2008 22:21:21 +0100
User-agent: GNUMail (Version 1.2.0)


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
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
A: standard GNUstep layout with some kind of prefix (/usr/GNUstep being currently the default)
B: FHS layout

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 it should go into the same plabe as or 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 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 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.


reply via email to

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