bugGNUstep - Bugs: bug #24670, gnustep-base installs by default...

Group
 
 

bug #24670: gnustep-base installs by default in SYSTEM

Submitter:  Nicola Pero <nico>
Submitted:  Tue 28 Oct 2008 08:32:11 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 30 Nov 2008 03:10:32 PM UTC, comment #8: 

For the record, I think the behavior is correct and I'm also very glad that no further complexity was introduced with new configure options and/or environment variables.

Thanks everyone!

David Ayers <ayers>
Group Member
Thu 27 Nov 2008 01:56:25 PM UTC, comment #7: 

Well, I tried to open this up for discussion on the mailing lists, but with minimal feedback and no apparent concern about making the change.  So I've gone ahead and removed the installation domain overrides in the base makefiles so that it will install into the local domain by default.
I think installing into the local domain does make sense, and if existing developers who might build/install from source are not concerned enough to watch the mailing list and discuss the issue, they will just need to adapt to the change by either getting used to base being in a new location or remembering to install it in the system domain themselves.

Richard Frith-Macdonald <CaS>
Group Member
Tue 28 Oct 2008 10:42:34 AM UTC, comment #6: 


> Would it be unreasonable for make to detect when it is being used on an existing
> system and act appropriately?


It's not unreasonable. :-)

One compromised solution that I may like is have a new ./configure option
for gnustep-make.

That option would basically decide if gnustep-make should install core
packages into System or Local.

By default, we set that option to install core packages into System.  So the big
pool of existing GNUstep users that build everything from source (starting
with gnustep-make upwards) won't see any changes. :-)

But I'd expect that packagers would change that option to disable that
behaviour when they create gnustep-make packages.  So if you are using a
gnustep-make preinstalled by your distribution (which presumably then comes
already with gnustep-base and other really core packages) if you install stuff
from source, it would then always go into Local and not overwrite your
distribution's stuff. :-)

Would that be a reasonable compromise ?  It should address the issues you
raised, preserve the current behaviour for hard-core GNUsteppers, but still
make life easy and predictable for the new GNUstep users.

I'm wondering if maybe the core packages should set not GNUSTEP_INSTALLATION_DOMAIN but some other variable which is more clearly
linked to this option, like BELONGS_TO_CORE or some other name. :-)

Thanks

Nicola Pero <nico>
Group Member
Tue 28 Oct 2008 10:14:22 AM UTC, comment #5: 


> 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
> an end-user installing into LOCAL


The only problem with this analysis is that it really only applies to new users ... and while we certainly want to cater for and encourage new users, I don't think we should ignore existing users who, for the moment, are probably a much, much larger group than the two you define.

So, the main groups are (I guess in descending order of size) are:
1. users building from source ... installing into /usr/GNUstep/System
2. users with pre-packaged systems ... irrelevant as they aren't building/installing
3. packagers
4. new users building installing from source.

What I'm suggesting is enhancing make so that it does the right thing as much as possible for each group, rather than ignoring the largest group.

Now, we can ignore 2 (they don't build/install) and 3 (they defined the domain themselves).

For group 4 we probably want to install in the FHS and put packages in the LOCAL domain (don't know if everyone agrees about that change though)/
For group 1 we probably want to install in the traditional GNUstep/NeXT style hierarchy and put things in the SYSTEM domain.

Would it be unreasonable for make to detect when it is being used on an existing system and act appropriately?  The easy way to do that would be to add a flag with the filesystem layout information to say whether GNUSTEP_INSTALLATION_DOMAIN in the individual packages should be ignored or not, and have this flag set for everything but an existing installation using the traditional layout.




Richard Frith-Macdonald <CaS>
Group Member
Tue 28 Oct 2008 09:34:45 AM UTC, comment #4: 


> I thought the way that GNUSTEP_INSTALLATION_DOMAIN was supposed to work
> was:
> 1. defined on the command line by packagers if they want a particular domain


Yes


> or
> 2. defined in each project's makefile, and used if the packager didn't specify a value)


No, GNUSTEP_INSTALLATION_DOMAIN should never be hardcoded in a
GNUmakefile.  Currently we do support it though; maybe this should be
disabled to protect users from software authors overwriting System stuff
and GNUSTEP_INSTALLATION_DOMAINs set in GNUmakefiles should be ignored.


> or
> 2. defined by gnustep_make, and used if neither the packager nor the project author > defined a value.


Well, the default - very predictably - is always LOCAL - as per GNU Coding
Standards.

Thanks

Nicola Pero <nico>
Group Member
Tue 28 Oct 2008 09:31:04 AM UTC, comment #3: 


> 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

Nicola Pero <nico>
Group Member
Tue 28 Oct 2008 09:19:29 AM UTC, comment #2: 

PS.  I thought the way that GNUSTEP_INSTALLATION_DOMAIN was supposed to work was:

1. defined on the command line by packagers if they want a particular domain
or
2. defined in each project's makefile, and used if the packager didn't specify a value)
or
2. defined by gnustep_make, and used if neither the packager nor the project author defined a value.

This seems the correct behavior to me ... the packager/builder has primary control, then the package author, then the make system (defaults to the local domain).

However, an option to allow the author to specify one domain to be used for the default gnustep layout, and an alternative domain to be used in FHS would make sense.


Richard Frith-Macdonald <CaS>
Group Member
Tue 28 Oct 2008 08:48:17 AM UTC, comment #1: 

Hmm .... almost marked this as invalid/declined out of hand.

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

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.

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.

Is there anything built in to the current gnustep-make to support this?




Richard Frith-Macdonald <CaS>
Group Member
Tue 28 Oct 2008 08:32:11 AM UTC, original submission:  

This is a bug - if you download and compile stuff from source,
it should always install into LOCAL.

Otherwise, if you use gnustep-make with an FHS layout,
if you download and compile gnustep-base from source, it will
end up being installed into /usr/bin, /usr/lib, etc instead
of /usr/local/bin, /usr/local/lib.  That (source code .tgz
downloaded from the internet that installs into /usr/bin
overwriting your system stuff) is extremely upsetting.

Packagers can obviously install wherever they want, in fact
they will install all packages into SYSTEM, not just gnustep-base

Thanks

Nicola Pero <nico>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ayers (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by nico (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-11-27 CaS StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2008-10-28 CaS StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code