James Amundson wrote:
> Thanks for the input. I have interspersed my comments below.
>
> On Sun, 2002-03-10 at 07:05, Vadim V. Zhytnikov wrote:
> > 1) Executables
> >
> > /usr/bin/ (%_bindir)
> >
> > main mxaima script and all other miscellaneous executables.
> > Usually wrapper scripts to some real executables. If we really
> > want different executables for different Maxima versions we
> > can make scripts maxima<ver> and link maxima to
> > maxima<ver>.
>
> The maxima wrapper script in cvs takes a version argument. I think we
> can maintain backward compatibility with the wrapper script, so one
> version should be OK.
>
Fine.
>
> > 2) Real executables
> >
> > /usr/lib/maxima/<ver>/ (%_libexecdir)
> > /usr/lib/maxima/<ver>/<lisp>
> >
> > (on my system libexec is mapped to lib).
>
> OK. That's what we have now.
>
> > 3) Share library files
> >
> > I definitely don't want to mix these files
> > with others so we have two options.
> >
> > /usr/share/maxima/<ver>/ (%_datadir)
> >
> > In this case we reserve this directory to
> > Maxima share library files _only_. But If we want
> > to install any other files into /usr/share/maxima/<ver>/
> > (e.g. emacs modes see below) then I propose
> >
> > /usr/share/maxima/<ver>/sharelib/
>
> OK. That makes sense. I guess "share" is being used in two different
> senses if we stick with the first example. Will it be confusing that the
> source files in "share" are installed in "sharelib"?
I proposed "sharelib" just for example. Maybe one can figure out some
better name. I had "maxima share library" in mind as replacement
for former /share*, /mac etc.
>
>
> > 4) Emacs *.el and related files
> >
> > Once again we have two options. We can either
> > use some standard directory for elisp files
> >
> > /usr/share/emacs/site-lisp/maxima/
> > (or /usr/share/emacs/site-lisp/maxima/<ver>)
> >
> > or Maxima share directory
> >
> > /usr/share/maxima/<ver>/emacs/
> >
> > In either case this directory must be added to the
> > directories where emacs can find them.
>
> I have spent hours trying to figure out the right thing to do for the
> emacs files. I will spare the list the boring details. Suffice it to say
> that I am not happy with anyone's procedure for installing emacs files.
> I propose to keep them in the maxima share directory and to provide a
> script that will add/remove the hooks to this directory either in the
> system emacs files or the users emacs files. For the rpm packaging,
> there would be separate maxima-emacs and maxima-xemacs packages
> independent of the base maxima packages.
>
OK.
>
> > 5) Documentation
> >
> > /usr/share/doc/maxima/<ver> (%_docdir)
> > or
> > /usr/share/doc/maxima-<ver>
> >
> > with subdirs ./emaxima, ./html and others.
>
> OK. I think I prefer the former.
>
I agree. I occasionally noticed that usually other
packages follows the latter convention. But
I don't know why and I'm perfectly sure that
there is no any strict rule about this.
>
> > 6) Info and man pages should go into standard directories
> >
> > /usr/share/info (%_infodir)
> > /usr/share/man (%_mandir)
>
> While that seems like the obviously correct solution, it violates the no
> conflicts between multiple version rule. Any ideas?
>
I understand this but I don't know good solution to the problem.
I'm sure that it is possible to extend the patch where info and man
looks for info/man pages but I don't think that it is common
practice and good idea in general.
>
> > 7) Some other miscellaneous directories
> >
> > /usr/lib/menu (%_menudir)
> > - menu entries
>
> I that's a RedHat-specific thing, isn't it? Any entries there may be a
> part of the RPM package only.
>
Yes.
>
> >
> > /usr/share/texmf/tex/latex/exmaxima
> > - TeX style files.
>
> I'm not thrilled about that one. I don't know if there is a
> platform-independent way to do the TeX style file installation. I think
> I would prefer the share directory.
>
Situation here is practically the same as with man and info.
Where is standard path where local TeX looks for style files
and we either have to place our *.sty in it or extend this path.
But in both cases having multiple emaxima.sty files
from different maxima versions will make lots
of confusion. How do you ensure that proper *.sty is
loaded? I have to idea.
>
> > /usr/share/icons (%_iconsdir)
> > - icons. BTW I could contribute .xpm icons but
> > they are modeled after icons of commercial Macsyma
> > icons (red M with the blue integral sign). Is it OK?
> > I don't think they copyrighted them but if any
> > trouble could expected I can make new ones.
>
> I really don't think we should copy the commercial Macsyma icon. Maybe
> we can find someone who would like to come up with a new icon for
> Maxima?
>
> > Finally some more proposals concerning new build system.
> >
> > It seems to me that contrib is not necessary in the Maxima
> > share library. Maybe it is better to place recently
> > contributed files directly in the appropriate subdirectory
> > of share library.
>
> I think there is a point to contrib. Code can be put in contrib before
> it has reached the level of scrutiny/testing that I would like to see
> for the more official maxima components. With the current state of the
> share directory the difference is not important, but I am thinking about
> the long term.
>
OK.
>
> > I think that it is necessary to add lisp initialization file
> > /usr/lib/maxima/<ver>/gcl/init.lisp
> > to GCL version of Maxima. And execute this file every
> > time GCL Maxima starts. This file should preallocate
> > some memory since without it GCL is terribly slow.
> > I hope that such GCL behavior will be improved
> > in the future but some memory preallocation is highly
> > desirable. In any case init.lisp can be empty.
> > Afterthought: the best way is to check for
> > /usr/lib/maxima/<ver>/gcl/init.lisp
> > and execute it is exists.
>
> We can do something like that. It doesn't have to be specific to GCL. We
> can allow for init's for any lisp implementation.
>
Good idea. Specific lisp initialization can be done in one init.lisp
file via feature conditionals.
>
> --Jim
--
Vadim V. Zhytnikov
<vvzhy@mail.ru>
<vvzhy@td.lpi.ac.ru>
<vvzhy@yandex.ru>