Make sure alpm_release is run at end of transaction.

[richard-uk1]

It is needed to run alpm_release at the end of all transaction, if it succeed or not, in order to remove the db.lck lock file. This lock file is created after a success run of alpm_trans_init.

[richard-uk1]

@guinux alpm_release is always run when the Alpm struct is dropped, which must happen even in a panic (Drop functions are still run in a panic). Is this sufficient?

[guinux]

It is alpm_trans_release which need to be run at the end of all transaction not alpm_release.

[guinux]

Sorry for the mistake on the function names.

[richard-uk1]

np. I still need to understand transactions!

[guinux]

To save you some time understanding the sources, here is how a transaction works:

• init a transaction (register transaction flags and lock databases) with alpm_trans_in it
• add a pkg to install (a ref to pkg in syncdb, can be run multiple times) with alpm_add_pkg
• AND/OR add a pkg to remove (a ref to a pkg in localdb, can be run multiple times) with alpm_remove_pkg
• AND/OR find pkgs to update and add them to install with alpm_sync_sysupgrade
• prepare the transaction (check deps and conflicts, data is a list of conflicts) with alpm_trans_prepare
• run transaction with alpm_trans_commit
• end transaction (unlock databases) with alpm_trans_release

[richard-uk1]

that's brill, thanks!

[guinux]

Between alpm_trans_prepare and alpm_trans_commit your can have access to the complete list of pkgs to install and remove (with deps and conflicts to remove) with alpm_trans_get_add and alpm_trans_get_remove

[richard-uk1]

I'm looking at modeling this as

enum Initialized {}
enum Prepared {}

impl Transaction<Initialized> {
   pub fn add(...) { ... }
   pub fn remove(...) { ... }
   pub fn prepare(...) -> Transaction<Prepared> { ... }
}

impl Transaction<Prepared> {
   pub fn commit(...) { ... }
}

These might not be the correct signatures, but hopefully you get the idea - the transaction is parameterised and different functionality is available depending on the state parameter. This is how http requests are handled in hyper (hyper http docs)

[guinux]

Looks good to me :)

[richard-uk1]

I'm currently struggling with transactions. There are various times when alpm_trans_prepare does nothing but returns success (if there is nothing to do). This makes it hard for me to strongly type my transaction.

The only solution I can see is exploit the internal structure of the transaction to get the state, but this would then be vulnerable to updates (a non-breaking change could break my code). Sadly I can't see any other way to do it, but I'll think about it and see if I have any ideas.

[guinux]

What about running alpm_get_add and alpm_get_remove after running a successful alpm_trans_prepare to check if there is something to do?

[richard-uk1]

Ooh good idea!

[richard-uk1]

An implementation is now comitted. It's testable using the examples/update.rs example.