> I inserted RH7 CD4 into my server and have been trying to install the
> Apache source (rpm -ivh apache-1.3.12-25.src.rpm). I see the hash
> marks like it installs but when I query (rpm -qa | grep apache) it is
> not installed. Any ideas? I want to recompile the server with LDAP
> support.
I'm pretty sure an "installed" SRPM isn't tracked in the database. I
venture to say, without a great deal of research, the code is just
unpacked. What follows are some notes I threw together a year or so ago
for those rare occasions when I decide to look into a package's source
code...
--
So you want to change some code and the package is distributed in a source
package file for the Red Hat Package Manager. But the question in your mind is
how the heck are you supposed to do this? Well, I got tired of not knowing
and with some valuable help from the Red Hat list here's what I learned.
The examples refer to the mythical foo-1.1 package which we intend to butcher
in the name of new features as well as maybe fix a bug or two. (No, we won't
actually change code. That's a much bigger topic.)
The source code packages come on the second Red Hat CD, and you'll find them
in the SRPMS directory. That's very similar to the way the binary package
files on the first Red Hat CD. Consistency is a wonderful thing, isn't it?
So you'll start off by installing the source package from the CD.
# mount /mnt/cdrom
# rpm -ivh /mnt/cdrom/SRPMS/foo-1.1-1.src.rpm
# umount /mnt/cdrom
This will put the package specfication ("spec") file in the
/usr/src/redhat/SPECS directory, but the pristine source code and any
patches will be put in the /usr/src/redhat/SOURCES directory. The pristine
source is actually stored in a *.tar.gz file and the various patches
are all stored in *.patch files. So, if you want to work with the code as
of the pristine source, you can work with the code in the *.tar.gz file.
In some cases you may find the only changes you need to make are to the spec
file, such as adding an option. In these cases you will just have to rebuild
the package after you make the change. Rebuilding the package is discussed
later.
But assuming you want to work on the latest version with all the patches,
you'll need to have the Red Hat Package manager apply the patches for you.
The "-bp" option specifies you want rpm to unpack the pristine sources and
apply the patches; nothing more. The results of this are placed in the
/usr/src/redhat/BUILD directory.
# cd /usr/src/redhat/SPECS
# rpm -bp foo-1.1.spec
Now you can get the patched source code and put it in a place where you
can refer to it. You'll want to do this for two reasons. First of all, you
will need to make a *.patch file of your own in the future. To do so, you'll
use a program called "diff" to compare the original source code to your
changed source code. Secondly, you may want to refer back to the original
source after you've made changes to your working copy. In this example, I'll
use my home directory as my workbench...
# cd /home/zztong
# mv /usr/src/redhat/BUILD/foo-1.1 .
# cp -R foo-1.1 foo-1.1.orig
Now the /home/zztong/foo-1.1 directory is where you do your programmer stuff.
You're going to want to poke around in the README files and get used to the
scripts and makefiles the previous programmer(s) used. Then you'll be ready
to change the code as needed. Depending on the software you might be able to
build and test within this directory. You'll have to make that call. Perhaps
working in your home directory doesn't make sense your case. If you can't
build in your home directory, you can make a *.patch file (which we'll cover
soon) and use RPM to build it. You're going to have to do that in the future
anyways.
Assuming you've made changes to the code and you're ready to make a *.patch
file you need to use the "diff" command to compare the original source tree
with your new source tree. To seperate your patch from the other patch files,
you might want to include something in the patch file name. I'll tack on my
usually "zztong" handle in the example. Then copy the *.patch file to where
RPM can find it during the build process.
# cd /home/zztong
# diff -Naur foo-1.1.orig foo-1.1 > foo-1.1-zztong.patch
# cp foo-1.1-zztong.patch /usr/src/redhat/SOURCES
Next you need to add some information about your patch file in the package
spec file. I like to keep a copy of the original spec file around in case
I make a mistake.
# cd /usr/src/redhat/SPECS
# cp foo-1.1.spec foo-1.1.spec.orig
# vi foo-1.1.spec
You'll probably find lines for previous patches in the spec file, so you
can just mimic them. If not, then you'll want to look into the "Maximum RPM"
book which I think you'll find is quite handy to have around. (You can also
read it at www.rpm.org if you want.) I'm going to short change this tutorial a
bit and just list the lines for the example. (I don't think I've explored this
part well enough to comment on it.) These are the lines we have to add to the
spec file.
Patch5: foo-1.1-zz.patch
%patch5 -p1 -b .zztong
You'll probably want to change the release number as well, which will be used
in the filename of the RPM and SRPM when you do a build. This will help you
(and others) keep track of the various versions of this package. You might
decide to change the version number too, but in this example we won't because
our mythical changes were very small. Also the name of the spec file contained
the version and we're too lazy to confront the issues related to that.
Version: 1.1
Release: 2
You might recognize these from the name of the package file. Do you recall
the name was foo-1.1-1.src.rpm for the SRPM and foo-1.1-1.i386.rpm for the
binary RPM. So, if we change the spec to use the values above, then they would
be named foo-1.1-2.src.rpm and foo-1.1-2.i386.rpm.
Now you can rebuild the package and create a new RPM and SRPM.
# rpm -ba foo-1.1.spec
Once this is done, your new RPM will be in the /usr/src/redhat/RPMS
directory, the new SRPM will be in the /usr/src/redhat/SRPMS directory,
and a new version of the source code with all the patches applied,
including your, will be in the /usr/src/redhat/BUILD directory. Of course,
you'll have to test your new RPM on another machine as even though the build
process installed all the package files on your development machine. It
might work because your development environment is there. Consider the
possibility your package refers to a file via a certain path. Your package
works on your development machine because that file exists, but since you
forgot to include that file in the RPM, it won't be installed on another
machine and then your RPM won't work. A more lucid discussion of this topic
can be found in section 11.5.2 (Testing Newly Built Packages) in the
"Maximum RPM" book.
If you're just going to use your package yourself, then you're all set. But
if you're thinking of distributing it you should check with the current
developers of the package about making changes. You don't want to release an
RPM that appears to usurp the project from them. Also, since they are the
heart of the project, they'll likely know if somebody has already accomplished
what you intend to do. You should be able to find the authors of the package
in the comments and/or documentation in the source package.
--
Bruce Tong | Got me an office; I'm there late at night.
Sr. Software Engineer | Just send me e-mail, maybe I'll write.
Electronic Vision / FITNE |
[EMAIL PROTECTED] | -- Joe Walsh for the 21st Century
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
