[Top][All Lists]

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

[bug #24670] gnustep-base installs by default in SYSTEM

From: Nicola Pero
Subject: [bug #24670] gnustep-base installs by default in SYSTEM
Date: Tue, 28 Oct 2008 09:31:05 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_5; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.2 Safari/525.20.1

Follow-up Comment #3, bug #24670 (project gnustep):

> AFAIK we have made no decision to move to using the FHS layout by default
> have no particular plan to do so. 

Well, all GNU/Linux distributions are using FHS layout and we can expect most
users to install GNUstep from their GNU/Linux distribution packages.  So, we
can expect most new users to be using FHS. ;-)

And if we're using FHS, it's a requirement to install into LOCAL.  Btw, it's
in the
GNU coding standards for packaging software.  While we're not following them
very strictly, installing into LOCAL is such a widespread and agreed
convention that 
it is really bad to break it. :-(

> What we actually need to handle this is an improvement/extension in the
> package (and presumably changes to the main project libraries and
applications if 
> necessary to take advantage of it) to distinguish between the situation
where a 
> packager decides where things are going to go, and the situation where the

> software is installed into the GNUstep default locations. 

"where the software is installed into the GNUstep default locations" for me
when a packager is packaging a GNUstep-only distribution.

Traditionally, if you just do 'make; make install' in GNUstep core, things
installed into the "GNUstep default locations", which really means according
to how a GNUstep-only distribution would install them.  But that's part of
a GNUstep-only distribution packager's job - it shouldn't be part of GNUstep

core.  GNUstep core only contains the source code, it shouldn't be doing
any packaging.

> As long as we are sticking with the GNUstep layout as our default (ie when

> built/installed by someone other than a packager), the correct place for
the base 
> library (and all the other code stuff) is /usr/GNUstep/System. 

There is no correct place for anything.  That is where a GNUstep-only
might install them, that's right.  But packaging is a separate topic.

Even in the case of a GNUstep-only distribution that puts gnustep-gui in
/usr/GNUstep/System, if I download the source code for gnustep-gui trunk
and compile it by hand, I expect it to install into /usr/GNUstep/Local,
overwriting my distribution's System installation.  So once I realize
trunk doesn't actually fix the problem I was having, I can wipe out 
/usr/GNUstep/Local and be back to my GNUstep-only distribution.  I'm not
messing up my System directory every time I try something new.

For me the problem is that there are two people that might be installing a 
GNUstep package (including a core package): 

 * a packager installing into SYSTEM - who we can assume to be an experienced
person with time at their hand to read the documentation and find the

 * an end-user installing into LOCAL - who we can assume will read no 
documentation and will get upset pretty immediately if things don't work out

in the obvious way (ie, according to the GNU coding standards, for example,
where stuff should install into LOCAL by default)

So, if we install by default into SYSTEM, then the packager has to do
but the end user gets a bad user experience.  If we install by default into
the end user gets a good user experience, but the packager has to do a
bit more ... set GNUSTEP_INSTALLATION_DOMAIN=SYSTEM before installing.
For a packager, that's not really such a big deal though.

Finally, just from a consistency standpoint, it's easier to understand if
everything always installs into the same location when compiled from source.
Otherwise every time you compile something you have to wonder where it
will end up into! ;-)



Reply to this item at:


  Message sent via/by Savannah

reply via email to

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