[lug] Managing RPMs

[Rob Nagler]

Kenneth D. Weinert writes:
> So, when I do a fix and it gets bumped to 2.1.0 then the entire 
> structure gets recreated? Just trying to be sure I understand.

Yes.  I don't think you need to bump the version unless there's an
incompatibility introduced.  I would recommend you write
backward-compatible interfaces.  I can say this "flippantly", because
we program in Perl which makes backwards compatibility easy.

You also probably want to decouple the RPM version (which gets bumped
on every build) and the "logical" version of your libraries.  We don't
put "logical" versions on RPMs, and instead use the date_time as the
version number.  It's then very easy to figure out which version files
were included in the RPM.  (All except the Bivio-bOP RPM, which we
supply publicly, since the general public expects "regular" versions.)

You can also play the Perl path game (type perl -V to see what I
mean).  I'm not a big fan of including multiple version directories in
paths, because it screws up when you delete files.

It's important to remember that you control everything so all you are
trying to do is create a migration plan.  You won't have to keep all
versions of all RPMs installed forever.  Eventually, you'll upgrade
all your software, and you can then delete unused
/usr/include/<company>-<version> directories (by deleting the older
RPMs).  This is similar to the way the kernel works.  You may have a
handful of kernels on your system, but you don't have every kernel
ever built for your platform.

Rob