[Rpm-maint] Rpm Database musings

Panu Matilainen pmatilai at laiskiainen.org
Sat Mar 9 14:55:37 UTC 2013

On 03/09/2013 03:19 PM, Thierry Vignaud wrote:
> On 7 March 2013 21:28, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
>> I wouldn't worry too much about hash algorithms and storage optimization at
>> this point: that's something that can be tweaked and tuned over time as long
>> as the cache structure is internally versioned so we know when we need to
>> rebuild it.
>> Right now I'm more interested in what the overall design of this all might
>> look like. Like said, I'd like to see the cache be a "read-only media" so
>> there are zero locking needed for queries that only need data from the
>> cache. It'll undoubtedly penalize writers (ie transactions) as the entire
>> cache probably needs to be regenerated even if just one package is
>> installed/removed, but then we're not in the "millions of transactions per
>> second" database business at all, in rpm's case painless (say, without
>> having a library steal your signals and blow up in all directions if you
>> miss a single iterator free, etc) and fast reads are what really counts I
>> think.
> Please don't be yum centric :-)

I wouldn't call it yum-centric, perhaps more just "traditional" :)

> where as yum & rpm only perform one transaction, URPM/urpmi (and thus
> rpmdrake as well as drakx -- Mageia ISO installer) usually split in several
> transactions of small packages:
> - sorting packages by deps
> - spliting in small transactions
> - foreach translation:
>    o download (if needed) only the packages need by this transaction
>    o verify those packages
>    o install those packages
> See http://search.cpan.org/~tvignaud/urpmi-7.19/urpm/main_loop.pm
> IMHO This makes urpmi more robust than yum in my experience.
> If we upgrade a whole system with lots of packages (says a couple thousands),
> urpmi can well perform ~100-200 rpm transactions.
> Having a quite a lot more expensive overhead per transaction would
> thus be a huge penalty for urpmi

...but yes, a fair point. I knew you guys are doing that, but apparently 
forgotten so thanks for the reminder :) And now that you mention it I 
think Suse does split transactions too.

Split transactions do have their advantages certainly, and there's no 
reason rpm couldn't do "sub-transactions" internally as well, but that's 
perhaps a topic for some other time...

	- Panu -

More information about the Rpm-maint mailing list