[pacman-dev] [libalpm] Installing and removing a package in the same handle lifecycle
Hi, I'm a PackageKit alpm backend contributor and I found a strange behavior when removing a package in the same alpm_handle_t lifecycle. Here you have the simplified workflow : alpm initialization new transaction install inkscape end transaction new transaction remove inkscape end transaction When removing the package, backend does an alpm_db_get_pkg (localdb, name) to get the package and then call alpm_remove_pkg with this found package. alpm_remove_pkg returns an error with 6 as errno. I looked in alpm_remove_pkg code and there is 3 cases returning such error. The one failing is pkg coming from localdb. I have no knowledge of libalpm internals but from the outside it looks like the package structure was copied ot the localdb in installation phase but the db field was not updated. I hope this is a bug that could be solved. Regards, Fabien
Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com> --- lib/libalpm/db.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/libalpm/db.c b/lib/libalpm/db.c index cef6c11..d679d8b 100644 --- a/lib/libalpm/db.c +++ b/lib/libalpm/db.c @@ -579,6 +579,10 @@ int _alpm_db_add_pkgincache(alpm_db_t *db, alpm_pkg_t *pkg) _alpm_log(db->handle, ALPM_LOG_DEBUG, "adding entry '%s' in '%s' cache\n", newpkg->name, db->treename); + newpkg->origin = (db->status & DB_STATUS_LOCAL) + ? ALPM_PKG_FROM_LOCALDB + : ALPM_PKG_FROM_SYNCDB; + newpkg->origin_data.db = db; db->pkgcache = _alpm_pkghash_add_sorted(db->pkgcache, newpkg); free_groupcache(db); -- 2.3.0
On 02/06/15 at 09:13pm, Fabien Bourigault wrote:
Hi, I'm a PackageKit alpm backend contributor and I found a strange behavior when removing a package in the same alpm_handle_t lifecycle. Here you have the simplified workflow :
alpm initialization new transaction install inkscape end transaction new transaction remove inkscape end transaction
When removing the package, backend does an alpm_db_get_pkg (localdb, name) to get the package and then call alpm_remove_pkg with this found package. alpm_remove_pkg returns an error with 6 as errno. I looked in alpm_remove_pkg code and there is 3 cases returning such error. The one failing is pkg coming from localdb.
I have no knowledge of libalpm internals but from the outside it looks like the package structure was copied ot the localdb in installation phase but the db field was not updated.
I hope this is a bug that could be solved.
Regards,
Fabien
Hi Fabien, Thanks for the bug report and for working on the PackageKit backend. Can you verify that the patch I sent fixes your issue? If you need to, you can download it from https://patchwork.archlinux.org/patch/2792/ apg
Hi Andrew, Thank you for this patch, the bug I was describing is now fixed. Regards, Fabien 2015-02-08 10:40 GMT+01:00 Andrew Gregory <andrew.gregory.8@gmail.com>:
Hi, I'm a PackageKit alpm backend contributor and I found a strange behavior when removing a package in the same alpm_handle_t lifecycle. Here you have the simplified workflow :
alpm initialization new transaction install inkscape end transaction new transaction remove inkscape end transaction
When removing the package, backend does an alpm_db_get_pkg (localdb, name) to get the package and then call alpm_remove_pkg with this found package. alpm_remove_pkg returns an error with 6 as errno. I looked in alpm_remove_pkg code and there is 3 cases returning such error. The one failing is pkg coming from localdb.
I have no knowledge of libalpm internals but from the outside it looks
On 02/06/15 at 09:13pm, Fabien Bourigault wrote: like
the package structure was copied ot the localdb in installation phase but the db field was not updated.
I hope this is a bug that could be solved.
Regards,
Fabien
Hi Fabien,
Thanks for the bug report and for working on the PackageKit backend. Can you verify that the patch I sent fixes your issue? If you need to, you can download it from https://patchwork.archlinux.org/patch/2792/
apg
participants (2)
-
Andrew Gregory
-
Fabien Bourigault