Re: tlug: Beginner Q: rpm's and xemacs

[Matt Gushee <matt@example.com>]

Umm. This all is getting into technicalities that I only vaguely
understand myself. If Steve's still online, maybe he can answer more
authoritatively. But in the meantime:

Darren Cook writes:

 > There is also something called xemacs-static-20... there, but as it is only
 > 2.5Mb I guess it doesn't mean statically linked?

Unless the people who made the package were on drugs, AFAIK static
always means statically linked. The thing about Emacs (XEmacs or any
other flavor) is that, although the whole thing is huge, only a fairly 
small portion is binary/platform-dependent. The bulk of it is in Lisp
code, which is what's so cool ... you write a few lines of Lisp and
Emacs becomes whatever you want it to be (except for, maybe, a really
good web browser ;-).

So that 2.5 Megs is probably just the binary executables. The rest is
in some other packages.

 > Right, I downloaded that, and did the same "rpm -i xemacs...rpm" command,
 > but it gives me the same two requirements, and now adds a third one:
 >   libcanna.so1.3
 > 
 > Is this the libc5/glibc confusion you mentioned? RedHat uses glibc, and I
 > thought Turbo Linux was as well.

No, this is unrelated to libc5/glibc. This is saying you don't have
Canna (one of several Japanese input methods, and probably the easiest 
to set up and use, though not necessarily the best), or you have the
wrong version, or RPM just can't find it. If you haven't installed
Canna, you can get it in RPM form. Should be available from TurboLinux.

 > >distribution, I *always* build it from an SRPM (if not from a tar
 > >archive). If you haven't built an SRPM before, it's usually quite easy
 > 
 > The S stands for source?

Bingo!

 > What exactly is an RPM? Is it (in windows terms) like a zip file of the
 > precompiled binary version, where the "rpm -i" command does the unzip,
 > double-clicks setup.exe and also decides the path to install it in for you?
 > That was the assumption I was working under.

Sort of like that, I suppose, but much more powerful. RPM also
maintains a database of the 
packages you have installed, so that you can use RPM commands to get
info about your software, and cleanly update or delete packages. I
should maybe mention that when RPM checks package dependencies, it
doesn't search your hard disk, it uses the info in the RPM
database. So if, for example, you have installed a non-RPM Canna
package, RPM doesn't know about it. No reason you can't use it, but
you then have to force RPM to ignore the dependency, like this:

# rpm -i --nodeps xemacs.xxxxx.rpm

RPM also allows you to configure, compile, and install a source
package (SRPM) with a single command. Pretty cool, huh?

By the way, you don't have to, but might want to, keep the /usr
hierarchy all-RPM, and install anything you compile yourself or
install from a non-RPM package in /usr/local. It cuts down on the
confusion.

 > 1.If I build from source, won't it still complain the .so files are missing
 > when I try to run it?

Not quite. If you, say, want to build XEmacs with PNG image support,
the compiler (well, really the linker) links the program with whatever 
libpng you have (it may not be compatible, but you often have a little 
bit of leeway). Binaries, in order to run, need the version they were compiled
against (usually just the major version -- i.e. libpng.so.2.1 is acceptable
for a program compiled with libpng.so.2.0, but libpng.so.1 is not). And
RPM, when you try to install a binary, looks for the right version *in
the RPM database*.

So, assuming the libraries you have are compatible with the program in 
the first place (and your development libraries should be the same
version as your runtime libraries -- e.g. libpng.1.0.3.rpm and
libpng-devel.1.0.3.rpm), your executable will find what it needs to run.

 > 2.Why would a source .tar.gz take more disk space than a precompiled
 > version? Or is this something about xemacs that I've yet to discover. Gulp.

It doesn't. But when you compile it, you need space for the source
tree *and* the installed files. Plus, the build process creates a
huge number of temporary files.

Hope this helps a little.

Matt
----------------------------------------------------------------
Next Nomikai: 20 November, 19:30   Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: 12 December, 12:30 HSBC Securities Office
----------------------------------------------------------------
more info: http://tlug.linux.or.jp Sponsors: PHT, HSBC Securities