Hi Mate!
Mate> Since I was on vacation, I am just picking up the thread now.
Mate> 1) /usr/local vs /usr.
Mate> Without making religious wars, let me say that if your /usr
Mate> partition full, you want to install elsewhere. Typically, there
Mate> is enough space on /usr/local---or you can move /usr/local to a
Mate> different partition (/usr is *much* harder to move b/c of its
Mate> size).
That's why the spec file should be relocatable. That way, those people
who want to do a non-standard /usr/local installation can do it easily.
Mate> Also, rpm is used on nonRH (or even nonlinux) systems. It is
Mate> better to comply with more general Unix practices than to adhoc
Mate> (RH) practice. Typically, an RH box is just part of a larger
Mate> network of machines, and then a rule that can be used on all
Mate> machines is favorable.
I don't know if /usr/local is a more widespread convention or not.
I do know that the *reason* for putting things in /usr/local in times
past was to separate out local packages from system packages and to
make it easier to keep track of the files and easy to do uninstalls
and upgrades.
RPM allows you to keep track of the files and to do uninstalls and
upgrades without regard to where you install the files.
Mate> But: my rpm is relocatable, so you can specify any instroot you
Mate> want on the command line.
Yes.
I looked at the new spec file and it works fine for me. I still
disagree with /usr/local as the default, but it doesn't matter since I
can do: ``rpm --prefix /usr'' to install where I like.
Mate> 2) Installing latex files in the teTeX tree.
Mate> IMO, not a good idea. What if I have a TeX different from teteX?
Mate> What if my teTeX is installed in /usr/local? What if $TEXMF is
Mate> readonly NFS mounted (as in our department)?
Hmmm... Good points.
Mate> (In my experience, it is not a good idea to install teTeX from
Mate> an rpm. teTeX has its own upgrading procedure, and it messes up
Mate> rpm's verify. Presently, teteX 1.0 has come out with bugfixes
Mate> almost daily; no rpm will keep up with it. Of course, your
Mate> milage may vary).
In my case, since I create my own RPM's of tetex-1.0, my mileage does
vary. However, I agree with your points in general.
I find it easier to code the RPM spec once, then drop in the latest
tarballs and recreate the RPM than to install from the tarball. In my
case, RPM is a convenient tool for *building* as well as
installing/upgrading packages. I do the same thing with the Linux
kernel (rebuild Redhat style packages of the kernel to intall).
Mate> What if I have a revtex.cls already? Which revtex.cls will be
Mate> found first? (It is another matter, that the teTeX FAQ does not
Mate> recommend putting the local additions in the main texmf tree;
Mate> see also texmf.cnf for TEXMFLOCAL).
Yes. Good points.
Mate> If the lyx rpm very much wants to install the .cls files, the
Mate> spec file should be smarter: it should first find out the local
Mate> value of TEXMF (or better yet, the value of TEXMFLOCAL).
This could be done by something like this:
unset TEXMF
TEXMF=`kpsewhich --expand-var '$TEXMF'`
Mate> 3) Simpler installation procedure.
Mate> This is what Kayvan wrote about his rpm. In what sense is this
Mate> true?
I think the original context in which I wrote that was in comparison
to a non-RPM installation, but I don't remember. Your RPM file's
installation process is simple as well.
Mate> (BTWY, I'd add `./configure --src' to Kayvan's rpm to configure lyx
Mate> for the local system).
Hmmm... I've never had a problem with LyX without doing this step. Is
it necessary?
Mate> So let us agree on what should be included in the rpm. If you
Mate> decide to have the .cls files installed, then it is better to
Mate> have say Kayvan maintain the rpm since I cannot test on my
Mate> system. Otherwise, I will be glad to maintain---but if somebody
Mate> else wants to do it, that is also fine with me.
I'll be happy to fix the RPM to add in the TEXMF/TEXMFLOCAL stuff for
the correct installation of the class files.
However, I don't want to step on your toes if you want to maintain the
RPM stuff.
Like I said before, I'll help generate "official" RedHat 6.0 RPM files
with whatever we all decide the final spec file should be. I didn't
even realize that there was already a spec file out there till it was
pointed out to me.
---Kayvan
