[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: System wide configurations
From: |
Schirmacher, Rolf |
Subject: |
RE: System wide configurations |
Date: |
Wed, 31 Oct 2007 22:30:45 +0100 |
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
>