bug-gnustep
[Top][All Lists]
Advanced

[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
and 
> have no particular plan to do so. 

Well, all GNU/Linux distributions are using FHS layout and we can expect most
new
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
make 
> 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
means
when a packager is packaging a GNUstep-only distribution.

Traditionally, if you just do 'make; make install' in GNUstep core, things
get
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
distribution
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,
without
overwriting my distribution's System installation.  So once I realize
gnustep-gui's
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
GNUSTEP_INSTALLATION_DOMAIN flag

 * 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
nothing,
but the end user gets a bad user experience.  If we install by default into
LOCAL,
the end user gets a good user experience, but the packager has to do a
little
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! ;-)

Thanks


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24670>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

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