bugGNUstep - Bugs: bug #24677, SystemPreferences installs by...

Group
 
 

bug #24677: SystemPreferences installs by default into SYSTEM

Submitter:  Nicola Pero <nico>
Submitted:  Tue 28 Oct 2008 08:38:05 AM UTC
   
 
Category:  Application 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 08:28:55 PM UTC, comment #3: 

Riccardo,

Think of it like this... standard UNIX applications install in /usr/local by default.  Whenever I build gcc or anything I expect it to install into /usr/local unless I tell it to install into /usr or the standard directory.

Given that this is the normal expectation, it could be disruptive to install into /usr/GNUstep/System when that is not what most users expect.

It's simple to keep installing things into the SYSTEM domain just by doing "make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install." Although, I would like for us to think about shortening that a little to make it easier.  I completely understand Nicola's point.

GC

Gregory John Casamento <gcasa>
Group administrator
Wed 29 Oct 2008 09:58:42 PM UTC, comment #2: 


> I disagree, it should install into SYSTEM, as all SYSTEM applications.


What is a "SYSTEM application" though ?

For me, it is something that comes with my system, as opposed to something
that I install manually myself (which is a "LOCAL application").

And the difference is useful because my system is usually installed from a CD
or using RPMs or DEBs or an installer ... and "system applications" are part
of that and I don't want to mess with them.

If I install manually stuff myself from source, I want it to go in a separate directory.  That way I know what I installed myself from source and what comes from the
system, and they are separate.  Eg, I can upgrade my system without destroying my
manually installed stuff, and installing manually stuff won't prevent me from upgrading.  If things go really wrong, I can easily uninstall everything I installed
manually - because it's in a separate directory.

This is all to say that what is a "SYSTEM application" and what is a "LOCAL
application" depends on how they are installed.  SystemPreferences - or Gorm -
can be a "SYSTEM application" or a "LOCAL application" depending on where
you get it from.  If it's part of your system installation (eg, an RPM) it's a
"SYSTEM application".  If you install it yourself from source it's a "LOCAL
application".

Now when you install SystemPreferences from sources, by definition it's
a LOCAL application and it should go in LOCAL. ;-)

A packager will need to install it in SYSTEM when creating the package.

I hope that clarifies the logic.

Thanks

Nicola Pero <nico>
Group Member
Wed 29 Oct 2008 06:06:10 PM UTC, comment #1: 

I disagree, it should install into SYSTEM, as all SYSTEM applications. Override should be possible, but should not be the default.

Riccardo Mottola <rmottola>
Group Member
Tue 28 Oct 2008 08:38:05 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 (Updated the item)
  • -email is unavailable- added by rmottola (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 StatusNone Fixed
        Assigned toNone gcasa
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-aa77.
    Corresponding source code