RPM Community Forums

Mailing List Message of <rpm-users>

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

From: Jeff Johnson <n3npq@mac.com>
Date: Sat 24 Jul 2010 - 00:23:24 CEST
Message-id: <4806642A-8B05-460F-B956-75F6B27CB62E@mac.com>

On Jul 23, 2010, at 5:43 PM, Tim Mooney wrote:

> 
>> 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.
> 

(aside)
Your post led me to revisiting pkg(5) on OpenSolaris. I sure
don't understand Sun's engineering methodology, with webrev's
and flag days and gating and more. One of these days I'll
have to see what all the fuss is about ...

>> 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 was quite excited when I saw that db-5.0.21 (or whatever its called ;-)
included sqlite3, and instantly leaped to db-5.0.21 and (in rpm-5.3.x)
sqlite3 is embedded (actually multiply embedded I think there's 3
different versions that RPM interfaces with these days).

I was hoping to support both a SQL and (their term, not mine) CRUD
access to an rpmdb.

But because of the manner Oracle chose to layer sqlite3 on top
of CRUD, it would take Yet Another schema change to achieve full
transparent dual SQL <-> CRUD access to an rpmdb.

That sent me looking for alternative approaches and sqlite3 has
has something called "virtual tables" for quite some years now that
could be used for transparent/dual access with SQL <-> CRUD.

I prototyped 5-10 "stores" using sqlite3 virtual tables (like /etc/{passwd,group})
which ends up with an architectural model or a loadable sqlite3 module
for the "virtual table" with RPM API's (I also prototyped SQL access onto
RPM header metadata) that _ALSO_ embed sqlite3 so its quite twisty.

In order to attempt a somewhat simpler "production" implementation, I
set off to use OpenPGP keys which have fewer secondary indices to
maintain, and the primary pubkey "blobs" are smaller (~1Kb) than RPM headers
(~36Kb).

That got me side-tracked into adding keypair generate and sign methods,
and automated hkp:// retrieval and validation from "keys.rpm5.org",
an SKS keyserver that is "burning-in" db-5.0.21 with DB_INIT_TXN
as used by "RPM ACID".

Then I got interested in ECDSA which led to adding LibtomCrypt and
Apple CDSA crypto @rpm5.org and ... (today's active task) a TPM crypto
layer *RPM's 7th crypto stack).

But I hope to get out of these crypto black holes and
get back to looking at dual SQL <-> CRUD access of an
rpmdb one of these weeks, sigh.

Just a long circuitous path ...


>>> 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.
> 

Good. DId you have to manually add a #define to enable Sun -lelf?

If so, that #define could likely be added easily to RPM's AutoFu.

(aside)
BTW, you might look at Ralf's RPM_CHECK_LIB which is really really spiffy.
I can hit a library API with like 5-6 lines in configure.ac

E.g. here's all that was needed to hit the IBM TPM 1.2 software
emulator checked in earlier today:

dnl # IBM TPM 1.2 software emulation
RPM_CHECK_LIB(
    [IBM TPM], [tpm],
    [tpm], [TPM_Init], [tpm/tpm.h],
    [no,external:none], [],
    [ AC_DEFINE(WITH_TPM, 1, [Define if building with IBM TPM 1.2 emulator])
    ], [])

You might want to swipe RPM_CHECK_LIB and add to your toolbox if still
packaging as you did before.

>> 
>>>> 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.
> 

Thanks. There's a fairly largish speed bump in neon with (iirc)
version 0.27. I need to burn out the old code pretty
soon and raise the minimum required neon version. I've
started the process but it will likely be a few more months
before I get around to ripping out the old code.

> 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.
> 

Yep. FYI -- RPM_CHECK_LIB() is perfectly prepared to extract neon pre-requsites
from a *.pc pkgconfig file. The other approach is through a *.la file
but there's too many linux agenda afoot that are attempting
	Kill! Kill! Kill! every *.la file everywhere.
for *.la to be useful (except on non-linux). I don't know
what the final answer will be yet.

>> 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.
> 

There's quite a few more RPM configure options that you might want to examine
in devtool.conf. The "maximally insane" set of options that I
build with on linux) are in the %system stanza in devtool.conf.

>> 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.
> 

Well you have a breadth of knowledge of how rpm is _SUPPOSED_ to perform
that is still unique. Ralf from OpenPKG has built RPM on more platform's
now, but you are still Avis to Ralf's Hertz in the realm of "portability". ;-)

73 de Jeff
Received on Sat Jul 24 00:24:10 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.