On Sep 4, 2008, at 4:53 PM, Alexey Tourbin wrote:

> On Wed, Aug 27, 2008 at 09:13:18AM -0400, Jeff Johnson wrote:
>> There's the Mandriva solution, called "file triggers", to the cache
>> update
>> problem in lib/filetriggers.c. I dislike several things with the the
>> specific
>> Mandriva implementation, but the idea is closest to being generally
>> useful IMHO.
>
> lib/transaction.c:
>   1880          if ((rpmtsFlags(ts) & _noTransTriggers) !=  
> _noTransTriggers)
>   1881              rpmRunFileTriggers(rpmtsRootDir(ts));
>
> Perhaps I need more general *mechanism* which can implement file
> triggers as a site/vendor *policy*, and which is not limited itself
> to file triggers.
>
> -		    rpmRunFileTriggers(rpmtsRootDir(ts));
> +		    rpmRunSitePosttrans(ts);
>

The forward looking goal is to make all scriptlets triggers.

If you think about it, scriptlets like %post are just "self-triggers".

> In rpmRunSitePosttrans, what possibly can be done is provide
> the ability for lua script to access installed and removed headers.
>
> That is, rpmRunSitePosttrans can call lua script
> /usr/lib/rpm/posttrans.lua with basically two arguments:
> the list of removed package instance numbers, and the list
> of added instance numbers (in the transaction ts).
>
> Also, it is necessary to provide lua bindings for 1) retrieving
> headers by instance, perhepas something like "h = getAddedHeader(num)"
> and "h = getRemovedHeader(num)"; and 2) retrieving header entries,
> e.g. "h.filenames".
>

I would do differently.

Getters/setters for rpmte, not get{Added,Removed}Header(), are what  
is needed.

Note that rpmte elements are detached from headers, reconnecting is a  
giant leap
backwards in time.

> Then the whole notion of "posttrans file triggers" or whatever  
> posttrans
> triggers can be implemented that posttrans.lua script.
>
> Now, it is easy to retrive headers of added packages, but it is a  
> tricky
> question if I can access headers of removed packages, i.e. the headers
> that's been removed from rpmdb while the transaction ts is not  
> finished
> yet.  There seems to be RPMDBI_REMOVED temporary database, but I am  
> not
> sure how it is supposed to work.

RPMDBI_ADDED and RPMDB_REMOVED were stubbed in while contemplating
generalizing the rpmdb match iterator to run across transactions.

I have yet to hear anyone requesting iterators on transaction  
elements, and so I haven't bothered to follow
through.

OTOH, saving added/erased headers in a backing store, and ripping out  
the lib/rpmal.c
in memory store, would be very useful. If the headers that compose a  
transaction
were saved in backing store persistently across invocations, then a  
transaction could be interrupted and resumed
without too much difficulty.

But the Berkeley DB haters have essentially frozen any possibility of  
better in rpm.

E.g. just yesterday, the consequences of --with-uniquename <-> static  
linking and the "bloat alerts!"
wrto Berkeley DB are being sounded in PLD. And so its simpler to not  
attempt any improvements
to rpmdb while the Berkeley DB haters are running around.

But that's just me, have fun!

73 de Jeff