On Jun 1, 2006, at 10:15 AM, Chowdhury, Chandan Dutta wrote:
Thanks a lot for all the info on database. I was trying to
understand the whole structure of rpm and did not find any
document describing the database. Anyway thanks a lot for the
usefull info. I will start playing with the --xml option to rpm
For sure if u have any other document on the database plz share it.
Thanks and Regards
Chandan
Hello all,
I have a few more question about the rpmdb
1. In the previous mail mentions about using sqlite for backend
instead
of bdb, is there a probability of rpm moving from bdb to a sqlite
based
backend.
rpm will use the highest performing, most reliable backend available.
That is still Berkeley DB, which is 2.6x faster than sqlite3 (after
tuning sqlite3, without tuning Berkeley DB),
and has far far more usage everywhere than sqlite3.
Sqlite3 was added to rpm because the Sleepycat license isn't GPL/
LGPL, and there are a significant number
of users who loathe Berkeley DB for various reasons.
2. What is the future of the rollback feature of rpm, I have seen
quite
a few mails saying not to use this feature, is it really deprecated?
Rollback has been part of rpm for years, and repackaging (i.e. saving
what was installed before erasing in a package)
is enabled by default in rpm-4.4.6.
Meanwhile, the ability to rollback packages imposes certain more
stringent conditions on rpm packages
which almost noone is checking. WORKSFORME, I've personally seen a
RHL9 -> Centos3 -> RHL9 system
rollback successfully, and I live and work on rollback enabled
systems daily.
So you'll have to shop your own answer. No matter what, rpm rollbacks
are certainly not deprecated.
3. I have a product which installs a group of rpms in one
transection(using yum/apt). For un-installation of the product I was
trying to use the same transaction key and identify the rpms for my
product. The problem is if I update one of the package in this group I
get a different transaction id. Does rpm keep track of transaction id
somehow?
Yes, the install transaction ID is added when a package is installed,
and an upgrade
(or replacement) of an installed package will have a different
transaction ID.
AFAIR the post install script of RPM is passed a value ("$1")
depending
on whether the rpm is installed for the first time or upgraded, in
such
a situation is the previous transaction id preserved ?
There are no complicated semantics or state preservation for
transaction ID. A transaction Id is a time stamp
of the transaction that is added to the package header when the
header is written to the rpmdb.
A time stamp is rather tricky to use reliably for identifying the
mapping of installed/removed packages
to transactions. For starters, if your clock was wrong, you're dead.
Another problem is that the time stamp
is in seconds, so two transactions in the same second (unlikely but
possible) will be mis-identified if using
only a transaction ID.
Other information has been added to track the many-to-many upgrade
pathways more reliably for rollback reversals
(or just tracking purposes). For starters, each package that is
upgraded includes the name, header SHA1 digest, and
package md5 digest of the previous packages that were upgraded or
obsoleted. That information can be displayed
as
rpm -qa --blink
(Note: "blink" is backward link, "flink" is forward link) Repackaged
packages have forward links to the package(s) that replaced,
with a similar
rpm -qp --flink /var/spool/repackage/*.rpm
Of course if you did not use rpm-4.4.5 or later to upgrade a package,
you won't see any links because the links ain't there, duh ;-)
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
