RE: System wide configurations

[Schirmacher, Rolf]

Sorry, please do not get me wrong. 

I totally agree that the issues I described are within the range of the
packangers and not within the range of octave core development or the make
process for octave . And I fully understand and agree with John on his
little personal interest in these issues. 

All I wanted to do was to explain what I understood the background of the
original post was...

Perhaps $prefix/share/octave/site is a bit too deep down the file system
tree  - btw, is it the only directory intended for site specific
configurations? - and at the same time parallel to the packages (which - for
the naive users - are a part of the binary release and not some uncontrolled
external addendum as from the octave development point of view) to be really
obvious as a configuration location to naive users. A higher level "site"
tree might clarify things and/or make them more simple. 

Think about the emacs site-lisp directory (which is higher level) or the
traditional /usr/texmf - /usr/local/texmf separation (which is obvious, but
does not bundle all of tex unter a common $prefix). 
But I might be biased by my experience - doing unix/linux system
administration in times where rpm was not yet invented and I had to do (and
understand) everything on my own and now being a non-privelleged windows
user (at work, not at home ;-). 

Rolf



> -----Original Message-----
> From: Quentin Spencer [mailto:address@hidden Behalf Of
> Quentin Spencer
> Sent: Wednesday, October 31, 2007 9:55 PM
> To: John W. Eaton
> Cc: Schirmacher, Rolf; address@hidden
> Subject: Re: System wide configurations
> 
> 
> John W. Eaton wrote:
> > On 31-Oct-2007, Schirmacher, Rolf wrote:
> >
> > | If you are not a developer, but simply a user of a binary 
> distribution (and
> > | to make things worse, assume working with windows and having no
> > | administrative rights :-(, then there is a problem how to 
> update to a new
> > | release.
> > | 
> > | The traditional, clean approach for naive windows users is 
> > | - uninstall octave x.x.old
> > | - install octave x.x.new
> > | Something like this was often requested to do some system 
> clean up before
> > | starting a new installation. Having 2 releases of one 
> software package in
> > | parallel without problems is still not that common on 
> some systems...
> > | 
> > | But then, everything under $prefix might/will be gone :-(
> > | This includes all changes you did to your files (o.k., 
> you should have send
> > | patches to improve octave for all...) and also any kind 
> of site/machine
> > | specific configuration, e.g. in 
> $prefix/share/octave/site. Nevertheless
> > | $prefix/share/octave/site sounds like the right place for such
> > | configurations and probably they should not get lost when 
> updating to octave
> > | x.x.new ...
> > | 
> > | Simply running install on an existing installation on the 
> other hand is
> > | often not a good idea either. You might end up with a 
> mixture which might be
> > | difficult to clean up later.
> > | 
> > | So, which directories shoud be preserved and how should 
> it be done best? How
> > | to make this simple for the users described at the 
> beginning of this mail?
> >
> > Are you asking me?  I think this is outside the scope of the normal
> > function of the install target in Octave's makefiles.  It 
> sounds to me
> > more like something that should be handled by people making binary
> > packages of Octave for various systems.  I'm not opposed to 
> changes in
> > Octave's build process that makes packaging easier, but patches for
> > any such changes will have to come from the people doing the
> > packaging as I have no idea what is needed and little personal
> > interest in this problem.
> >   
> 
> John is right. In RPM-based Linux distributions, for example, RPM can 
> flag certain files as config files that should not be 
> overwritten when 
> upgrading to a new version. Typically, the new file is written as 
> <file>.rpmnew so that a user can go back and compare to determine 
> whether that file should be changed. Whether or not a file is in /etc 
> has nothing to do with this, as a file can be flagged this way 
> regardless of its path. If you want RPMs to not overwrite particular 
> files, file a bug with the package for your distribution 
> asking for that 
> file to not be overwritten. So, this should really have nothing to do 
> with octave itself and is really an issue for the packagers.
> 
> Quentin
>