Re: System wide configurations

[Petr Gajdos]

Hi,

thanks Rolf. Simply, I am a new packager of Octave and I try to understand it.

I know that's my work :) and I know about %config (or %config(noreplace) respectivelly) but I don't know *which*files*should*be*marked* with this flag. Currently there is no file marked with %config in Octave in our distribution, unfortunatelly. This means that no (config) file will be preserved during update for example from openSUSE 10.2 to 10.3 because of the newer version of Octave.

Then would be nice to know what kind of files could appear under $prefix/share/octave/site and for example what is the distiction (where/when are used) between

/usr/share/octave/2.9.12/m/startup/octaverc and

/usr/share/octave/site/m/startup/octaverc respectivelly.

The reason of my interest is to find right solution, which depends on your answer, though.

Moreover, every system-wide configuration file should be at least symlinked in /etc. However note that there is a problem with rpm and symlinking of whole directory tree (for example $prefix/share/octave/site) in this context .

Hence my proposal is:

/usr/share/octave/2.9.12/m/startup/inputrc

/usr/share/octave/2.9.12/m/startup/inputrc

/usr/share/octave/site/m/startup/octaverc

(another one ??)

mark with %config(noreplace) and

• symlink them to /etc _or_
• move them to /etc and convince Octave somehow that they are there, advices are strongly wellcome :).

What should *I* do??

Have nice day

Thanks

Petr

Dne Wednesday 31 October 2007 22:30:45 Schirmacher, Rolf napsal(a):

> 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

> >

>