[pacman-dev] [PATCH] Remove pmsyncpkg_t
Hi! Since the patch is quite long and it depends on my working branch, I don't send it here directly. It can be found in my repo (it is a new branch): http://repo.or.cz/w/pacman-ng.git ---quote--- Remove pmsyncpkg_t pmsyncpkg_t data sructure was removed: 1. pmpkg_t.reason is used instead of pmsyncpkg_t.newreason. (The target packages come from sync repos, so we can use this field without any problems. Upgrade transaction also uses this field to store this info.) 2. pmsyncpkg_t.removes was moved to pmpkg_t.removes. This step requires careful programming, because we don't duplicate packages when we add them to trans->packages. So we modify sync pkgcache when we add this transaction-only info to our package. Hence it is important to free this list when we remove any package from the target list (remove_unresolvable, remove_conflicts, trans_free), otherwise this could confuse the new sync transactions (with non-pacman GUI). Overall, our code became ~100 line shorter, and we can call our helper functions directly on trans->packages in sync.c, we don't need to maintain parallel package lists. ---------- I simply merged pmsyncpkg_t to pmpkg_t, so the code became notable cleaner(?) and shorter, but I am not very satisfied, see the commit message. Bye
On Sat, Mar 7, 2009 at 8:29 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Hi!
Since the patch is quite long and it depends on my working branch, I don't send it here directly. It can be found in my repo (it is a new branch): http://repo.or.cz/w/pacman-ng.git
---quote--- Remove pmsyncpkg_t
pmsyncpkg_t data sructure was removed: 1. pmpkg_t.reason is used instead of pmsyncpkg_t.newreason. (The target packages come from sync repos, so we can use this field without any problems. Upgrade transaction also uses this field to store this info.) 2. pmsyncpkg_t.removes was moved to pmpkg_t.removes. This step requires careful programming, because we don't duplicate packages when we add them to trans->packages. So we modify sync pkgcache when we add this transaction-only info to our package. Hence it is important to free this list when we remove any package from the target list (remove_unresolvable, remove_conflicts, trans_free), otherwise this could confuse the new sync transactions (with non-pacman GUI).
Maybe a stupid comment, without looking at the code, but couldn't we make sure the removes fields are cleared when creating a new transaction?
Overall, our code became ~100 line shorter, and we can call our helper functions directly on trans->packages in sync.c, we don't need to maintain parallel package lists.
That's quite nice indeed.
On Sat, Mar 7, 2009 at 8:29 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Hi!
Since the patch is quite long and it depends on my working branch, I don't send it here directly. It can be found in my repo (it is a new branch): http://repo.or.cz/w/pacman-ng.git
---quote--- Remove pmsyncpkg_t
pmsyncpkg_t data sructure was removed: 1. pmpkg_t.reason is used instead of pmsyncpkg_t.newreason. (The target packages come from sync repos, so we can use this field without any problems. Upgrade transaction also uses this field to store this info.) 2. pmsyncpkg_t.removes was moved to pmpkg_t.removes. This step requires careful programming, because we don't duplicate packages when we add them to trans->packages. So we modify sync pkgcache when we add this transaction-only info to our package. Hence it is important to free this list when we remove any package from the target list (remove_unresolvable, remove_conflicts, trans_free), otherwise this could confuse the new sync transactions (with non-pacman GUI).
Maybe a stupid comment, without looking at the code, but couldn't we make sure the removes fields are cleared when creating a new transaction?
We could do it, and it would be safer and maybe cleaner. I didn't choose that method, because I don't like needless operations. (We have usually one [real] transaction. And we use sync transaction for -Sy, [but the trans type could be changed here].) First I preferred "free removes list in sync_addtarget", but I realised that there are several places in the code where we add sync targets (and we also need an assumption here: we don't add duplicated targets). I don't know which method is better, if you all prefer xav's method, I will make a separate patch to tweak this part. Bye
participants (2)
-
Nagy Gabor
-
Xavier