RPM Community Forums

Mailing List Message of <rpm-users>

Re: Issues with rpm-5.0.3 - overwrites other RPM's

From: Tim Mooney <Tim.Mooney@ndsu.edu>
Date: Fri 23 Jul 2010 - 23:43:32 CEST
Message-ID: <alpine.SOC.2.01.1007231531250.19631@dogbert.cc.ndsu.NoDak.edu>
In regard to: Re: Issues with rpm-5.0.3 - overwrites other RPM's, Jeff...:

> Hi Tim!
>
> On Jul 23, 2010, at 3:12 PM, Tim Mooney wrote:
>
>> In regard to: Issues with rpm-5.0.3 - overwrites other RPM's, Robert Cohen...:
>>
>>> We've built, and had been using for years, our own instance of rpm 4.0.3, and it worked a treat. Our platform was Solaris 8/9/10, on sparc.
>>
>> I did the same with rpm 2.5.6 and then 4.4.[679].
>>
>
> ;-) Now there's a whole lotta history in that transition ;-)

:-)  You're not kidding.  4.4.x was a quantum leap after so many years
on 2.5.6.

> Most of that portability from 4.4.9 -> 5.1.9 came from OpenPKG methodology
> and Ralf Eneglschall's attention to details.

I remember all the emails.

> Note that the transition for rpm-5.1.9 -> 5.2.1 is pretty easy, but
> that is very much not true moving to "RPM ACID" as in rpm-5.3.x,
> where no "compatibility" is promised, and the conversion issues
> aren't yet sufficiently well defined to attemp a shrink wrapped
> rpmdb transition.

:-)  Based on my upgrade patterns for rpm itself, it will probably be
very safe by the time I'm contemplating that change.

Of course, with the final displacement of Solaris in my environment,
there's a good chance I won't even be running Solaris when I make my next
workstation change.  If that happens, I probably won't be building my own
RPM anymore.

> But rpm-5.3.2 with a clean install is fine, its only the schema changes,
> and the transition that is rugged. The performance is considerably
> better, an Berkeley DB ACID eliminates most side-effects from interrupted
> installs, etc, etc.

How's RPM's support for Berkeley DB 11.x, or whatever Oracle is calling it
now?  I'm surprised I haven't seen any posts on the mailing list about it;
with all the people that have asked about SQLite support over the years,
I would think that the SQLite compatibility in 11.x would have some people
chomping at the bit to try it.

>> I had issues with the dependency generator not finding ELF library
>> provides correctly after the update, but discovered that was because
>> 5.1.9 doesn't build with libelf support by default (you have to request
>> it).  Once I did that and then hacked out tools/debugedit so that wasn't
>> built, everything worked very well.
>>
>
> SIs you use the Sun ELF or something else? It likely would not be
> hard to add a test for Sun ELF implementation to rpm's AutoFu if useful.

I'm using Sun's libelf.  The tests are already there (some from me, based
heavily on work from Frank Cusack) in RPM's configure, they're just not
enabled on solaris unless you ask for them.  It's no problem, it just
surprised me.

>
>>> Even the build process for rpm5  seemed dodgy, as I had to do things like copy in find-provides, find-requires, and configure them into the macros file by hand.
>>
>> I don't remember having to do any of that.  I certainly customized a macro
>> or two, but nothing major.
>>
>>> The build of 5.0.3/5.2.1 was against gcc 3.4.3, using GNU make, and involved the  installlation of beecrypt, zlib, and popt from 3rd party sources, into /usr/local/rpm, before attempting to build rpm as I have been unable to get the copies distributed with RPM to build.
>>
>> I built my own copies of stuff beforehand in many cases.  I'm using
>> the Sun Workshop 12u1 compilers, so if anything your builds should have
>> been easier.  I probably had the most trouble getting rpm to use my
>> copy of neon, but that's because neon builds static libraries only by
>> default and there's no good way for RPM's configure to discover that neon
>> depends on things like libssl and libkrb5.
>
> For reference: What version of neon?

When I was building 4.4.9 (and having the same issues), it was 0.26.x.
When I built rpm 5.1.9, I built against 0.29.3.

I've mentioned the neon issue on the mailing list a couple times before,
for example in a post about 4.4.x on Thu, 4 Jan 2007.  It's just an issue
with rpm's configure not being able to guess any of the myriad
dependencies that libneon might have.  It's not RPM's fault, there's just
no easy way to deal with the problem.

> Also for reference: If you send along the configure options you used
> (like in config.log) then I'll add to devtool.conf as a "reference"
> Solaris configure options.

The configure line is pretty standard:

./configure --prefix=%{_prefix} --exec-prefix=%{_prefix} \
     --build "$BUILD_TARGET" \
     --libdir=%{_libdir} \
     --mandir=%{_mandir} \
%ifos solaris
     --with-libelf \
%endif
     --localstatedir=%{LOCALSTATEDIR} \
     --with-path-database=%{LOCALSTATEDIR}/rpm \
     --with-path-cfg=%{SYSCONFDIR}/rpm

Getting the environment (CC, CFLAGS, LDFLAGS, etc.) set up has a bigger
influence on the process than anything.  The one I'm using probably
has a bunch of stuff that's now unnecessary with rpm 5.1.x (evolutionary
left-overs from 4.4.x days).  For example, with 4.4.x it was useful to
include

 	-xmemalign=8i

in CFLAGS because certain structs weren't being aligned correctly and
it was causing segfaults on sparc in intGetEntry, see my post to the
list on Tue, 26 Jun 2007 for more info.

Stuff like that likely isn't needed anymore, so I would have to weed
out some of the junk from CFLAGS before publishing.

> Glad to here you're still using RPM ;-)

I'm still here!  I haven't been posting much since there hasn't been
a lot that I'm able to help with -- most of the stuff on the rpm5.org
lists is developer-related or targeted at a specific distribution that
I don't have any experience with.

Tim
-- 
Tim Mooney                                             Tim.Mooney@ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
Received on Fri Jul 23 23:43:53 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.