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:41:23 CEST
Message-id: <84A66367-0AB8-4E26-B63C-70D40AF5B863@mac.com>

On Jul 23, 2010, at 6:23 PM, Jeff Johnson wrote:

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

I should perhaps describe what I mean by "embedded" wrto
sqlite3 more carefully because (if you are still targeting
multiple platforms) you might find the functionality useful.

Anything and everything that one can do with /usr/bin/sqlite3
can now be done with a macro.

The macro embedded syntax looks like this


while the scriptlet embedded syntax looks like

	%post -p "<foo OPTIONS ARGS>"

To illustrate, this snippet of shell (for a sqlite3 rpmdb)
	/usr/bin/sqlite3 /var/lib/rpm/Packages << GO_SYSIN_DD
	select * from Packages;
can also be done like
	%{sql /var/lib/rpm/Packages:select * from Packages;}
as well as (but you would likelier do INSERT INTO ...)
	%post -p "<sql /var/lib/rpm/Packages>"
	select * from Packages;

i.e. its quite possible to update sqlite3 databases using *.rpm

Of course you could do the same with /usr/bin/sqlite3 run as a script
too, but then you get into dependencies and ordering and all the "traditional"
packaging baggage. The embedded syntaxes can just be used.

IIRC, you had a very methodical approach to paths etc used in your
pacakages. With emebedded sqlite3 you might even be able to move that
into a sqlite3 database instead of using different macro files as a store.

OTOH, no reason to change what isn't broken whatsoever.

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