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

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #24673: Gorm installs into SYSTEM by default

Submitted by:  Nicola Pero <nico>
Submitted on:  Tue 28 Oct 2008 08:35:14 AM UTC  
 
Category: GormSeverity: 3 - Normal
Item Group: BugStatus: Fixed
Privacy: PublicAssigned to: Gregory John Casamento <gcasa>
Open/Closed: Closed

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gcasa (Posted a comment)
  • -unavailable- added by nico (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 27 Nov 2008 04:56:10 PM UTCgcasaOpen/ClosedOpen=>Closed
    Thu 27 Nov 2008 04:47:07 PM UTCgcasaStatusNone=>Fixed
      Assigned toNone=>gcasa

    Back to the top


    Powered by Savane 3.1-cleanup1