bugGNUstep - Bugs: bug #24673, Gorm installs into SYSTEM by...

Group
 
 

bug #24673: Gorm installs into SYSTEM by default

Submitter:  Nicola Pero <nico>
Submitted:  Tue 28 Oct 2008 08:35:14 AM UTC
   
 
Category:  Gorm Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 27 Nov 2008 04:47:07 PM UTC, comment #5: 

That being said...

Could we shorten the variable to DOMAIN or GS_DOMAIN?  Typing GNUSTEP_INSTALLATION_DOMAIN when doing an install is a little hard on the fingers. ;)

Anyway... closed.

GC

Gregory John Casamento <gcasa>
Group administrator
Thu 27 Nov 2008 04:44:38 PM UTC, comment #4: 

I see and I agree with what you're saying.   Blowing away the SYSTEM installation by default is not advisable.

GC

Gregory John Casamento <gcasa>
Group administrator
Thu 27 Nov 2008 03:55:21 PM UTC, comment #3: 

By the way, the real question should be - why is Gorm
overring the defaults and forcing installation into SYSTEM
instead of letting the user decide ?

Installation into SYSTEM is extremely surprising and unfriendly
if you download a source package.

Imagine if you were able to download Apple's AppKit source code
to compile it and you'd install it to try your own built of
the latest AppKit (or XCode or whatever).  Would you want it
to automatically destroy your normal AppKit/XCode installatoin
so that if it doesn't work you'll have to reinstall your
entire OS again, or would you rather have it install in
some "Local" domain where you can try it out but if it
doesn't work you can always remove the directory and go
back to your System installation ?

This is exactly what we're talking about here.  Someone has
got GNUstep installation - probably from packages or a
distribution or a startup system or his OS, and downloads
Gorm (or gnustep-gui or something else) source code to try
out the latest version.  Are we going by default to destroy
his GNUstep installation with his experimental build - so that
he'll have to reinstall all of GNUstep and possibly the entire
OS if it's a GNUstep-based OS, or are we going to put the
experimental build into Local so that they can still go back to
their normal System by just removing the Local stuff ?

Thanks

Nicola Pero <nico>
Group Member
Thu 27 Nov 2008 03:46:18 PM UTC, comment #2: 

Packagers can do whatever they want, because they are experienced
users whose main job is to work on installation stuff.  Hopefully
they will easily find out about the GNUSTEP_INSTALLATION_DOMAIN
flag and can install wherever they want. :-)

It's normal users who are disadvantaged by the current setup.

If they download a new version of Gorm from the internet and
install it to try it out, it will overwrite the Gorm version
that came with their GNUstep distribution (eg, Debian or
whatever GNUstep distribution they're using - including one
that puts things into /usr/GNUstep).  Because 'normal users'
are, well, normal users, it may be hard for them to figure
things out - and permanently destroying/overwriting packages
that came with their OS System installation is really
unfriendly towards them! ;-)

Eg, if they have installed GNUstep using some easy-to-use
startup or installation packaging system, they'll already
have a version of Gorm in /usr/GNUstep/System.  If they
download Gorm and build it manually from source from the
internet to try out a new release, it should go into
/usr/GNUstep/Local without overwriting their
/usr/GNUstep/System installation.
If they mess up with their source code hack, they can always
delete the stuff from /usr/GNUstep/Local to go back to
their System distribution. :-)

The reason everything used to be installed into System when
compiling from source is just that we never had or supported
RPMs or DEBs or any type of GNUstep distribution other than
compiling from source.  As we move towards supporting more
and more easy-to-use GNUstep packages and installation options
for new users, we should be more careful about these things
and try to make sure compilation/installation from source
doesn't conflict with these packages and ready-made
startup/installation options that we're trying to breed. :-)

So, we need to start making a difference between Local and
System and understand that you install in System when you're
building a system, and you install into Local if you're
building your own local version of some package.

Thanks

Nicola Pero <nico>
Group Member
Thu 27 Nov 2008 02:52:48 PM UTC, comment #1: 

Isn't it just as easy for the packager to put it into the LOCAL domain if he/she wants to rather than changing it globally?

Why are we making this decision based on what's good for FHS?  Why, indeed, are System and Local tied to /usr and /usr/local respectively?

GC

Gregory John Casamento <gcasa>
Group administrator
Tue 28 Oct 2008 08:35:14 AM UTC, original submission:  

This is a bug - everything should always install into LOCAL
unless told otherwise.

We now fully support FHS which means that anything installing
into SYSTEM could be overwriting system stuff in /usr/bin,
/usr/lib, etc. Obviously any source tarball should not do
that and install politely install itself into LOCAL (which
becomes /usr/local on FHS) unless told otherwise.

Packagers will obviously install everything into SYSTEM, but
that's their responsibility.

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 gcasa (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 gcasa Open/ClosedOpen Closed
    2008-11-27 gcasa StatusNone Fixed
        Assigned toNone gcasa

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code