Being Newer Than Red Hat

[pri.blu at iadonisi.to (Paul Iadonisi)]

On Mon, 2002-08-12 at 17:28, Kent Borg wrote:
> On Mon, Aug 12, 2002 at 05:00:05PM -0400, Paul Iadonisi wrote:
> >   Wow, a packaging discussion that didn't generate a flamewar. 
> > Awesome!  ;-)
> 
> I didn't realize the risk I was running.  Then again, I consciously
> decided to ask this list instead of the rhl list I am on, maybe I knew
> more than I knew.

  Some lists more than others.  This list is usually a little more low
key (save the Overqualified->H1B->Union->Farmer one a few weeks ago).


> First, it seems a really big part of rpms are the spec files.  Is
> there a good documention on writing in that "language"?

  I'll echo what someone else said: the docs suck.  Well, they're not
blatantly inaccurate, as far as I know, but they do lack a lot and some
of them are out of date.  Most of what I learned was by digging into
existing src rpms to see what they were made of.
  The bulk of spec files are plain old scripts.  The header is a list of
keywords followed by colons that list source files, patch files, author,
license, etc.  Most are self explanatory and included in the stock rpms
Red Hat ships.  So you can pull apart one of them and just modify the
spec file to suite your needs.  If your building a newer version of
something that Red Hat already ships (as you are with cvs), it can
almost be trivial.  Just do the following (assuming Red Hat 7.3):

o First, I recommend setting up an ~/.rpmmacros file with the following
contents:
=-=-=- cut here -=-=-=
%_topdir		/home/iadonisi/redhat
%_builddir		%{_topdir}/BUILD
%_rpmdir		%{_topdir}/RPMS
%_sourcedir		%{_topdir}/SOURCES
%_specdir		%{_topdir}/SPECS
%_srcrpmdir		%{_topdir}/SRPMS
%packager		Kent Borg <kentborg at borg.org>
%distribution		Kent Borg's Linux <kentborg at borg.org>
=-=-=- cut here -=-=-=

and create the ~/redhat directory with all of the subdirectories above. 
Red Hat recommends that all rpm building be done as a non-root user and
this facilitates that (an alternative is to chown everything under
/usr/src/redhat to your username).  Don't forget to create at least an
i386 subdirectory underneath the RPMS directory.  Others that are
advisable are i586, i686, athlon, and noarch as appropriate.

o Next grab the original Red Hat src.rpm for cvs and install it.

# rpm -ivh cvs-1.11.1p1-7.src.rpm

This will place, as someone else pointed out, the spec file under
~/redhat/SPECS and the sources under ~/redhat/SOURCES.

o Next put the new cvs-1.11.2 tarball in ~/redhat/SOURCES.

o Edit ~/redhat/SPECS/cvs.spec and change the version of the rpm.(in
this particular case, there are two '%define's at the top of the spec
file.  Change cvsbase to 1.11.2 and cvspatch to the null string -- I
think just keeping '%define cvspatch' should take care of it).  You may
want to change the 'Release:' line as well -- that's the number that
comes after the 'version-' in an rpm.  I usually tack on some
distinguishing letters (.plus.01.pri) to signify that it is a custom
built rpm and not part of Red Hat's distribution.

o What I usually do next is create the src.rpm first.  This gets around
some problems with earlier version of rpm that may have since been
solved, but I still do it out of habit:

rpmbuild -bs --rmsource --rmspec ~/redhat/SPECS/cvs.spec

o Now comes the tough part.  Rebuild the rpm, but it is highly likely
that some of the [nine] patches in this spec file will fail since they
are meant for cvs-1.11.1p1.  You'll need to, one at a time, take the
failed patch, determine if it is no longer needed, and retrofit it for
the new version of cvs if it is needed.  (Also note that the header only
lists the patches with the 'Patch0:' - 'Patch8:' lines.  The actual
application of the patches happens later in the spec file in the '%prep'
section.  When adding or removing patches, you need to change both
places -- the one that lists the name of the patch, and the one applies
it.)  You may opt to remove all the 'Patch#:' and '%patch#' lines and
just go with the stock cvs-1.11.2 release -- no patches.
Oh, and to build the binary rpm, do this:

rpmbuild --rebuild ~/redhat/SRPMS/cvs-1.11.2-1.src.rpm


> Second, I grabbed the srpm, and installed it.  Then I did the
> rpmbuild, and installed the result of that.  It seemed to work.  (Did
> it?)  My question: aren't the sources still going to be sitting
> somehwere?  (Where?)

That's actually a little redundant.  Well, it depends on how you built
it.  Installing a src.rpm doesn't update any rpm database, but just puts
the files in the locations I and Derek Atkins pointed out.  But you can
either rebuild an rpm from a spec file with

rpmbuild -ba ~/redhat/SPECS/cvs.spec

or from the src.rpm with the earlier command above.  Building from a
src.rpm will clean up after itself.  The spec file method might leave
files around if you don't use the '--rmsource --rmspec' options.

> Third is a question I already answered for myself.  There are two
> kinds of signatures for rpm files.  Plain old "md5" and "md5 gpg".  If
> you do an "rpm --checksig somepackage.rpm" wanting to verify that it
> is a genuine Red Hat package, you want to get something like
> "XFree86-libs-4.1.0-15.i386.rpm: md5 gpg OK", not
> "cvs-1.11.2-5.i386.rpm: md5 OK".  Anyone can build an "md5 OK" rpm (I
> did) but only someone with Red Hat's secret key can gpg-sign an RPM.
> So when checking RPMs (and you do want to do so), don't just look for
> a lack of complaint on bad signatures, make sure all expected gpg
> signed packages are actually *gpg* signed.
> 
> I do note that the rawhide source rpm I downloaded does not check out:
> 
>   cvs-1.11.2-5.src.rpm: md5 (GPG) NOT OK (MISSING KEYS: GPG#897DA07A)
> 
> Whazzup?  Are betas signed with a different key?  (I guess that is my
> third question.)

On a Red Hat 7.3 system, you should see a BETA-RPM-GPG-KEY file in
/usr/share/rhn.  However, from looking at Limbo2, the
signing/verification mechanism looks to be in a little bit of a state of
flux.  I'll let you know when I have it all figured out.  I think all
you need to do (with 7.3, at least) is import that BETA-RPM-GPG-KEY into
your keyring.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets