[pacman-dev] CVS update of pacman-lib (14 files)
Date: Saturday, February 17, 2007 @ 03:55:06 Author: aaron Path: /home/cvs-pacman/pacman-lib Modified: .cvsignore (1.4 -> 1.5) lib/libalpm/add.c (1.114 -> 1.115) lib/libalpm/backup.c (1.10 -> 1.11) lib/libalpm/backup.h (1.5 -> 1.6) lib/libalpm/package.c (1.70 -> 1.71) lib/libalpm/package.h (1.29 -> 1.30) lib/libalpm/po/de.po (1.5 -> 1.6) lib/libalpm/po/fr.po (1.3 -> 1.4) lib/libalpm/po/hu.po (1.3 -> 1.4) lib/libalpm/po/pt_BR.po (1.2 -> 1.3) lib/libalpm/remove.c (1.63 -> 1.64) src/pacman/downloadprog.c (1.14 -> 1.15) src/pacman/log.c (1.30 -> 1.31) src/pacman/trans.c (1.35 -> 1.36) * A whole mess of backup changes - the code should be clearer, more organized, commented, and have worthwhile variable names now - proactive backup=()s now work. That is, adding a file to a backup array does what it should on the upgrade to that package, no longer forcing you to wait a full upgrade cycle for it to take effect * ldconfig was being run twice on an upgrade operation - fixed * fixed another pm_fprintf/printf output corruption with the progress bars * refactored some duplicate code for adjusting 'requiredby' lists * Added config.rpath to .cvsignore ---------------------------+ .cvsignore | 1 lib/libalpm/add.c | 668 ++++++++++++++++++++------------------------ lib/libalpm/backup.c | 4 lib/libalpm/backup.h | 2 lib/libalpm/package.c | 114 +++++++ lib/libalpm/package.h | 2 lib/libalpm/po/de.po | 33 +- lib/libalpm/po/fr.po | 337 +++++++++++----------- lib/libalpm/po/hu.po | 337 +++++++++++----------- lib/libalpm/po/pt_BR.po | 325 ++++++++++----------- lib/libalpm/remove.c | 103 +----- src/pacman/downloadprog.c | 5 src/pacman/log.c | 4 src/pacman/trans.c | 5 14 files changed, 1000 insertions(+), 940 deletions(-) The diff is longer than the limit of 39KB.
On 2/17/07, Aaron Griffin <aaron@archlinux.org> wrote:
* A whole mess of backup changes - the code should be clearer, more organized, commented, and have worthwhile variable names now - proactive backup=()s now work. That is, adding a file to a backup array does what it should on the upgrade to that package, no longer forcing you to wait a full upgrade cycle for it to take effect
This needs some more testing to verify it's working 100% so I don't want push out another RC just yet... feel free to use the PKGBUILD at http://archlinux.org/~aaron/pacman/PKGBUILD if you want to build from CVS and test it. It works in all the tests I did, but they weren't exhaustive tests. It's getting silly calling these "RC"s anymore... i guess it should have been "beta" or something to begin with... ah well.
2007/2/17, Aaron Griffin <aaronmgriffin@gmail.com>:
On 2/17/07, Aaron Griffin <aaron@archlinux.org> wrote:
* A whole mess of backup changes - the code should be clearer, more organized, commented, and have worthwhile variable names now - proactive backup=()s now work. That is, adding a file to a backup array does what it should on the upgrade to that package, no longer forcing you to wait a full upgrade cycle for it to take effect
This needs some more testing to verify it's working 100% so I don't want push out another RC just yet... feel free to use the PKGBUILD at http://archlinux.org/~aaron/pacman/PKGBUILD if you want to build from CVS and test it. It works in all the tests I did, but they weren't exhaustive tests.
It's getting silly calling these "RC"s anymore... i guess it should have been "beta" or something to begin with... ah well.
Does this change with backup means that that bug with removing file from NoUpgrade resulting in overwriting it on first update (_only_ on first update)? If yes, then we can get rid of NoUpgrade from default pacman.conf. -- Roman Kyrylych (Роман Кирилич)
On 2/17/07, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
Does this change with backup means that that bug with removing file from NoUpgrade resulting in overwriting it on first update (_only_ on first update)? If yes, then we can get rid of NoUpgrade from default pacman.conf.
Should work now. I'll have to test.
On 2/17/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 2/17/07, Aaron Griffin <aaron@archlinux.org> wrote:
* A whole mess of backup changes - the code should be clearer, more organized, commented, and have worthwhile variable names now - proactive backup=()s now work. That is, adding a file to a backup array does what it should on the upgrade to that package, no longer forcing you to wait a full upgrade cycle for it to take effect
This needs some more testing to verify it's working 100% so I don't want push out another RC just yet... feel free to use the PKGBUILD at http://archlinux.org/~aaron/pacman/PKGBUILD if you want to build from CVS and test it. It works in all the tests I did, but they weren't exhaustive tests.
More a coding style thing: lib/libalpm/remove.c: + _alpm_pkg_update_depends(info, 1 /*is a remove*/); Why do you need this remove parameter? You do things two different ways in the function now- once using the remove value passed in, and once like this: if(handle->trans && handle->trans->packages && handle->trans->type == PM_TRANS_TYPE_REMOVE) { It seems like checking this at the top of the function and storing it to a variable then would be more effective then having a "magic parameter". -Dan
On 2/17/07, Dan McGee <dpmcgee@gmail.com> wrote:
More a coding style thing: lib/libalpm/remove.c: + _alpm_pkg_update_depends(info, 1 /*is a remove*/);
Why do you need this remove parameter? You do things two different ways in the function now- once using the remove value passed in, and once like this: if(handle->trans && handle->trans->packages && handle->trans->type == PM_TRANS_TYPE_REMOVE) {
It seems like checking this at the top of the function and storing it to a variable then would be more effective then having a "magic parameter".
Yeah, what I was trying to do was steer away from tying that function to a transaction object. In fact, that one is even done wrong, and in the case of an upgrade there are two transaction objects, so this function needs a transaction passed in. I'll probably move this to trans.c, and remove the "remove" parameter, and pass in a transaction object.
participants (4)
-
Aaron Griffin
-
Aaron Griffin
-
Dan McGee
-
Roman Kyrylych