Menu
▾
▴
plplot-devel
|
From: Alan W. I. <ir...@be...> - 2003-02-18 16:54:09
|
OCTAVE_M_DIR = /usr/share/octave/site/m OCTAVE_OCT_DIR = /usr/lib/octave/2.0.16.92/oct/i386-pc-linux-gnu Rafael, this is a bad result. It means nobody can try plplot without having root privilege, and once you have made such an install it is non-trivial to un-install. (With my normal prefix of /usr/local/plplot_at, rm -rf /usr/local/plplot_at/* is a wonderfully simple way to uninstall....;-)) Also, ignoring the install prefix seems to go against the design philosophy of autotools where every effort seems to be made to honor the installation prefix. Please change to $prefix/share/octave/site/m and $prefix/lib/octave/2.0.16.92/oct/i386-pc-linux-gnu at least. (I am being over-specific about the version here which I presume is fully configured in your present scheme.) Something similar is done for the python packages where the python plplot-related modules and extension modules are installed in $prefix/lib/python2.1/site-packages/ (I am being over-specific about the version here which is fully configured.) Also, there is a configurable 3-line module, examples/python/plplot_python_start.py(.in), that keeps track of the install location if different from standard. With the python scheme, $prefix=/usr works well for packagers, and also everything works well for those who want to install to their own personal prefix without having to be root. Please adopt the same idea for octave. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-02-18 17:17:28
|
* Alan W. Irwin <ir...@be...> [2003-02-18 08:52]: > OCTAVE_M_DIR = /usr/share/octave/site/m > OCTAVE_OCT_DIR = /usr/lib/octave/2.0.16.92/oct/i386-pc-linux-gnu > > Rafael, this is a bad result. It means nobody can try plplot without having > root privilege, and once you have made such an install it is non-trivial to > un-install. (With my normal prefix of /usr/local/plplot_at, > > rm -rf /usr/local/plplot_at/* > > is a wonderfully simple way to uninstall....;-)) Also, ignoring the install > prefix seems to go against the design philosophy of autotools where every > effort seems to be made to honor the installation prefix. > > Please change to > > $prefix/share/octave/site/m > and > $prefix/lib/octave/2.0.16.92/oct/i386-pc-linux-gnu This problem has already been detected by Joao, and I worked in a fix since yesterday evening. During the day today, I ran some experiements to be sure that things work. At any rate, this is fixed and cvs committed. At any rate, I have been aware of the problem from the very beginning, and I do not need a long and tedious course on "How $prefix is useful and wonderful" :-) -- Rafael |
|
From: Rafael L. <lab...@ps...> - 2003-02-18 17:28:11
|
* Alan W. Irwin <ir...@be...> [2003-02-18 08:52]: > and once you have made such an install it is non-trivial to un-install. > (With my normal prefix of /usr/local/plplot_at, > > rm -rf /usr/local/plplot_at/* Wrong. Just call "make uninstall" and all the files that have been installed (regardless if under $prefix or not) are removed. Automake is great. -- Rafael |
|
From: Alan W. I. <ir...@be...> - 2003-02-18 18:31:13
|
On Tue, 18 Feb 2003, Rafael Laboissiere wrote: > * Alan W. Irwin <ir...@be...> [2003-02-18 08:52]: > > > and once you have made such an install it is non-trivial to un-install. > > (With my normal prefix of /usr/local/plplot_at, > > > > rm -rf /usr/local/plplot_at/* > > Wrong. Just call "make uninstall" and all the files that have been > installed (regardless if under $prefix or not) are removed. > > Automake is great. Yes it is, but it is also far from perfect so to encourage users to use uninstall is just plain wrong unless they don't mind if it screws up. First, the automake documentation specifically spreads some doubt about uninstall "Note that uninstall' is not meant as a replacement for a real packaging tool." That doesn't sound like it is a high maintenance priority with the autotools developers. Also even if autotools uninstall is completely bug-free it is not clear that uninstall will actually work properly if you have gone outside the autotools paradigm. Sorry, Rafael, but I like the KISS principle so I am going to stick with rm -rf and a special prefix for each of my handful of different tarball installs. Of course if a real packaging tool is used like debs or rpms I am happy to go with those since their package uninstalls are heavily tested by many users. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
|
From: Rafael L. <lab...@ps...> - 2003-02-18 20:19:11
|
* Alan W. Irwin <ir...@be...> [2003-02-18 10:29]:
> Yes it is, but it is also far from perfect so to encourage users to use
> uninstall is just plain wrong unless they don't mind if it screws up.
>
> First, the automake documentation specifically spreads some doubt about
> uninstall
>
> "Note that uninstall' is not meant as a replacement for a real packaging
> tool."
Your interpretation of this sentence in the manual is very biased. The
authors are just stating that "make uninstall" does very simple things,
actually only deletion of files. It is like "make install", that just
install files. There could be a sentence in the manual like this:
"Note that install is not meant as a replacement for a real packaging tool."
^^^^^^^
Would you then say that "make install" is not trustful?
> That doesn't sound like it is a high maintenance priority with the
> autotools developers. Also even if autotools uninstall is completely
> bug-free it is not clear that uninstall will actually work properly if you
> have gone outside the autotools paradigm.
Why are you suggesting that make uninstall is buggy? Your statements sound
like FUD.
> Sorry, Rafael, but I like the KISS principle so I am going to stick with
>
> rm -rf
>
> and a special prefix for each of my handful of different tarball installs.
> Of course if a real packaging tool is used like debs or rpms I am happy to
> go with those since their package uninstalls are heavily tested by many
> users.
At any rate, I never pretended that "make uninstall" would work in any
possible case. Neither that you should start using it. I just pointed out
that "make uninstall" take care of removing every file installed through
"make install", including those installed elsewhere than $prefix. Period.
--
Rafael
|
|
From: Alan W. I. <ir...@be...> - 2003-02-18 21:53:00
|
On Tue, 18 Feb 2003, Rafael Laboissiere wrote: I don't agree with your interpretation, but let's forget any more discussion on this topic....EOT Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the Canadian Centre for Climate Modelling and Analysis (www.cccma.bc.ec.gc.ca) and the PLplot scientific plotting software package (plplot.org). __________________________ Linux-powered Science __________________________ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X