R devel - Jun 2004 - Installer package destroys permission settings on /Applcations (PR#7025)

Full_Name: david Reitter
Version: 1.9.1
OS: Mac OS X 10.3
Submission from: (NULL) (18.85.44.174)


The installer package seems to change the permissions on the /Applications
folder (and probably on other folders as well), which means that a normal user
(that does not happen to have user id 501) cannot open the Applications folder
anymore. Both group and user are changed to id '501' (which doesn't
exist on my
system). 501 is usually the first user on a system.
Also, it seems to change permissions of the root directory /.

Running Disk Utility ("repair permissions") helps in such a case --
provided you
are able to run Disk Utility without accessing your Applications folder (which
might be hard for the non-techie).
 
The libxml package that is included does the same kind of BS, but this time with
the less important /usr folder.

I could reproduce the problem by installing R again after I ran the system's
repair permissions script. 
I wonder if this is a general problem with Apple's installer.

Thanks for raising this problem. I agree, the installer should not 
change the permissions on /Applications (but user can decide to install 
the application somewhere else and move it to /Applications later as a 
temporary solution)

It only affects the directory where you choose to install R.app (the 
few KB application). So the rest of your system is safe (at least)

As for the R.framework: it should stay in /Library/Frameworks in this 
release as well as for 1.9.0. So nothing changes there

I've just upload a new version of the installer on CRAN. It will take 
till tomorrow to propagate on the web.

Apart from this (serious) issue: user should upgrade always to the 
latest version of R

As said in the ReadMe file, you should install the libxml2 package if 
you use Panther (which seems to be your case).

stefano


On Jun 26, 2004, at 2:17 AM, reitter@mle.media.mit.edu wrote:
> Full_Name: david Reitter
> Version: 1.9.1
> OS: Mac OS X 10.3
> Submission from: (NULL) (18.85.44.174)
>
>
> The installer package seems to change the permissions on the 
> /Applications
> folder (and probably on other folders as well), which means that a 
> normal user
> (that does not happen to have user id 501) cannot open the 
> Applications folder
> anymore. Both group and user are changed to id '501' (which
doesn't
> exist on my
> system). 501 is usually the first user on a system.
> Also, it seems to change permissions of the root directory /.
>
> Running Disk Utility ("repair permissions") helps in such a case
--
> provided you
> are able to run Disk Utility without accessing your Applications 
> folder (which
> might be hard for the non-techie).
>
> The libxml package that is included does the same kind of BS, but this 
> time with
> the less important /usr folder.
>
> I could reproduce the problem by installing R again after I ran the 
> system's
> repair permissions script.
> I wonder if this is a general problem with Apple's installer.
>
> ______________________________________________
> R-devel@stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>

On Jun 26, 2004, at 9:41 AM, stefano iacus wrote:
> Thanks for raising this problem. I agree, the installer should not 
> change the permissions on /Applications (but user can decide to 
> install the application somewhere else and move it to /Applications 
> later as a temporary solution)
I'd say that it shouldn't read "the installer should", but
rather "the
package creator should" - again the package is very badly created - 
same as the R 1.9.0 one and defies all mechanisms Apple provides in the 
Installer. It's not a fault of the Apple's Installer but rather how the 
package was created (Apple's Package Manager provides ways to set 
rights correctly). Unfortunately the only way to get proper 
installation of R (if you didn't build you own package) is to 
re-compile it and use corresponding make install commands. I have 
addressed this issue previously and even created a package template, 
but sometimes things just don't change :(

Cheers,
simon