[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: installation domains
Re: installation domains
Thu, 30 Oct 2008 22:21:21 +0100
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
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
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,
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
as long as it stays by default to SYSTEM, it is fine. THis is actually
needed for what I write below.
causes it to install into System by default, instead of Local
5. we add a new option to gnustep-make's ./configure, something like
which can be used to change where stuff with GNUSTEP_CORE_PACKAGE=YES
installed by default. We default
to System but suggest that packagers packaging gnustep-make change it
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
all GNUmakefiles in devmodules
that currently have GNUSTEP_INSTALLATION_DOMAIN=SYSTEM to instead
Thus the result... would be the same.
The only real visible change for people compiling everything from
would be 1., from /usr/GNUstep to /usr/local/GNUstep,
but the new ./configure options would allow packagers to ship a
I'd even avoid that change, for the reasons above.
Let me sum up. We have mainly two install scenarios corssed by three
A: standard GNUstep layout with some kind of prefix (/usr/GNUstep
being currently the default)
B: FHS layout
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
further elaborations? I wrote this in response to your bug report: by
default I would expect that libobjc or SystemPreferences go into my