[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.4-163-gfb09d35
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The official pacman repository".
The branch, master has been updated
via fb09d35e6a24ef433005728c77453bce99efd010 (commit)
via 33e3182dbd1ad9b68f72914abbf4a93a97b0d79b (commit)
via a8ee1854135f333091337e3dbcb1f96cdb1aab01 (commit)
via 84283672853350a84d2a71b72dc06e180cad1587 (commit)
via dd98aa8564a21ed43782704bf9feb5b2b114825f (commit)
via a422f6e39c9c60b89269c2b09e697a9eb142b904 (commit)
via f671147282e0f5c6a2e05c8cb7a0d5b72ef8cb61 (commit)
via ae5ef3b90fcad0627d450f0be6ea04dbea2019e2 (commit)
via 584ffa6aef13d0933ad4930ab9cb70d3af2977ff (commit)
via d5278ebb3ba94efdc9fffb7924ac66b6747d9011 (commit)
via f43805d875ad5c672afbbfff48bded2087204773 (commit)
via 8248b4bfb1abe175d73e20106a18172da5296836 (commit)
via e80232f24c51838d3f4ccff1fbc9c8fda87e1ecb (commit)
from 663408532ae852e7123da6b9658df1cacc0c642d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit fb09d35e6a24ef433005728c77453bce99efd010
Author: Xavier Chantry
Add SyncFirst option.
This patch offers a way to fix FS#9228. By putting "SyncFirst = pacman" in pacman.conf, the version check will happen before the transaction really starts, and before any replacements is made. Otherwise, no version check is done.
The sync301 pactest was updated to use this SyncFirst option.
Example session with SyncFirst = pacman, and a newer pacman version available : $ pacman -Su (or pacman -S <any targets>) :: the following packages should be upgraded first : pacman :: Do you want to cancel the current operation :: and upgrade these packages now? [Y/n]
resolving dependencies... looking for inter-conflicts...
Targets: pacman-x.y.z-t
Total Download Size: x.xx MB Total Installed Size: x.xx MB
Proceed with installation? [Y/n] n
As Nagy previously noted, doing this check on any -S operations might look intrusive, but it can be required. For example, the case where you want to install a package with versioned provisions, using a pacman version which didn't support that feature yet (and there is already a newer pacman in sync db supporting it).
Signed-off-by: Chantry Xavier
Signed-off-by: Dan McGee
\o/
commit f43805d875ad5c672afbbfff48bded2087204773 Author: Chantry Xavier
Date: Sat May 10 18:47:42 2008 +0200 Cleanup usages of alpm_list_find and alpm_list_remove.
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and _alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by a more general alpm_find_pkg_satisfiers with a cleaner implementation. before: alpm_db_whatprovides(db, targ) after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ)
Warning: pkg literal also satisfies pkg. But in most cases we called what_provides if we didn't find a literal.
* remove satisfycmp and replace alpm_list_find + satisfycmp usage by _alpm_find_dep_satisfiers. before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp) after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep)
Warning: possible slowdown, the old way just stopped after a satisfier (which is ideal in checkdeps), now we scan the whole db.
* remove _alpm_pkgname_pkg_cmp, which was used with alpm_list_remove, and use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead.
Imho this is ugly. First we find it, then we again find it via list_remove. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Nagy Gabor wrote:
commit f43805d875ad5c672afbbfff48bded2087204773 Author: Chantry Xavier
Date: Sat May 10 18:47:42 2008 +0200 Cleanup usages of alpm_list_find and alpm_list_remove.
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and _alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by a more general alpm_find_pkg_satisfiers with a cleaner implementation. before: alpm_db_whatprovides(db, targ) after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ)
Warning: pkg literal also satisfies pkg. But in most cases we called what_provides if we didn't find a literal.
I know, it's not exactly equivalent but I think it makes more sense that way and as you noticed, it works the same for our use case.
* remove satisfycmp and replace alpm_list_find + satisfycmp usage by _alpm_find_dep_satisfiers. before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp) after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep)
Warning: possible slowdown, the old way just stopped after a satisfier (which is ideal in checkdeps), now we scan the whole db.
Right, I knew about that too, I just wanted to keep the code as clean as possible and didn't find another way. Though it might be worth to do some benchmarking / profiling. If it's really too bad, it will have to change.
* remove _alpm_pkgname_pkg_cmp, which was used with alpm_list_remove, and use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead.
Imho this is ugly. First we find it, then we again find it via list_remove.
Yeah, it's not ideal either. But neither are dummy pkg or fake asymmetric cmp functions. I just preferred it like that. Imo the real problem here is that our data structures suck and are inefficient. Linear search ftw. Anyway, other better suggestions for these 3 points are always welcome.
Nagy Gabor wrote:
commit f43805d875ad5c672afbbfff48bded2087204773 Author: Chantry Xavier
Date: Sat May 10 18:47:42 2008 +0200 Cleanup usages of alpm_list_find and alpm_list_remove.
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and _alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by a more general alpm_find_pkg_satisfiers with a cleaner implementation. before: alpm_db_whatprovides(db, targ) after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ)
Warning: pkg literal also satisfies pkg. But in most cases we called what_provides if we didn't find a literal.
Yes, there is no problem with this (I just emphasized it). I like the new function better because I think find_satisfiers is quite a common task. Btw, as I see, after this patch pacman -S 'kernel26>=2.6.24' automagically works, which is cool imho.
I know, it's not exactly equivalent but I think it makes more sense that way and as you noticed, it works the same for our use case.
* remove satisfycmp and replace alpm_list_find + satisfycmp usage by _alpm_find_dep_satisfiers. before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp) after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep)
Warning: possible slowdown, the old way just stopped after a satisfier (which is ideal in checkdeps), now we scan the whole db.
Right, I knew about that too, I just wanted to keep the code as clean as possible and didn't find another way. Though it might be worth to do some benchmarking / profiling. If it's really too bad, it will have to change.
One more thing, the result of alpm_find_dep_satisfiers should be freed, which is forgotten (memleak). Remember, that the old list_find was a boolean function, it was modified in order to handle causingpkg for -Ru. No doubt, this will be slower. The average slowdown of (successful) dependency check will be about 2x. (considering only the real calculations, not disk read etc.) The question is that overall this will be notable or not, this needs testing, indeed. Basically, I don't prefer clean code over "performance", so I think this should be changed (*).
* remove _alpm_pkgname_pkg_cmp, which was used with
alpm_list_remove,
and use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead.
Imho this is ugly. First we find it, then we again find it via list_remove.
Yeah, it's not ideal either. But neither are dummy pkg or fake asymmetric cmp functions. I just preferred it like that. Imo the real problem here is that our data structures suck and are inefficient. Linear search ftw.
(*) is also holds here. However, performance is not an issue here, just simply we do an "unneeded" task here, which I find ugly. alpm_list_find compare functions could be easily killed, but list_remove is quite a complicated function, thus "reimplementing" won't work. I think in this case keeping pkgpkgnamecmp was better, even if it was ugly. An alternative idea: alpm_list_find_node, which returns with an alpm_list_t node, not the ->data; and reimplement alpm_list_remove_node, but with two param list (head) and node. This information is enough to cleanly remove that node, and can be cut from the current list_remove (by splitting that function). Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Nagy Gabor wrote:
Nagy Gabor wrote:
commit f43805d875ad5c672afbbfff48bded2087204773 Author: Chantry Xavier
Date: Sat May 10 18:47:42 2008 +0200 Cleanup usages of alpm_list_find and alpm_list_remove.
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and _alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by a more general alpm_find_pkg_satisfiers with a cleaner implementation. before: alpm_db_whatprovides(db, targ) after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ) Warning: pkg literal also satisfies pkg. But in most cases we called what_provides if we didn't find a literal.
Yes, there is no problem with this (I just emphasized it). I like the new function better because I think find_satisfiers is quite a common task. Btw, as I see, after this patch pacman -S 'kernel26>=2.6.24' automagically works, which is cool imho.
I am glad you liked at least one thing about my patch :)
I know, it's not exactly equivalent but I think it makes more sense that way and as you noticed, it works the same for our use case.
* remove satisfycmp and replace alpm_list_find + satisfycmp usage by _alpm_find_dep_satisfiers. before : alpm_list_find(_alpm_db_get_pkgcache(db), dep, satisfycmp) after : _alpm_find_dep_satisfiers(_alpm_db_get_pkgcache(db), dep)
Warning: possible slowdown, the old way just stopped after a satisfier (which is ideal in checkdeps), now we scan the whole db.
Right, I knew about that too, I just wanted to keep the code as clean as possible and didn't find another way. Though it might be worth to do some benchmarking / profiling. If it's really too bad, it will have to change.
One more thing, the result of alpm_find_dep_satisfiers should be freed, which is forgotten (memleak). Remember, that the old list_find was a boolean function, it was modified in order to handle causingpkg for -Ru. No doubt, this will be slower. The average slowdown of (successful) dependency check will be about 2x. (considering only the real calculations, not disk read etc.) The question is that overall this will be notable or not, this needs testing, indeed. Basically, I don't prefer clean code over "performance", so I think this should be changed (*).
I think these are valid concerns, I will send a patch which should address them, please review it :)
* remove _alpm_pkgname_pkg_cmp, which was used with
alpm_list_remove,
and use _alpm_pkg_find + alpm_list_remove with _alpm_pkg_cmp instead.
Imho this is ugly. First we find it, then we again find it via list_remove.
Yeah, it's not ideal either. But neither are dummy pkg or fake asymmetric cmp functions. I just preferred it like that. Imo the real problem here is that our data structures suck and are inefficient. Linear search ftw.
(*) is also holds here. However, performance is not an issue here, just simply we do an "unneeded" task here, which I find ugly. alpm_list_find compare functions could be easily killed, but list_remove is quite a complicated function, thus "reimplementing" won't work. I think in this case keeping pkgpkgnamecmp was better, even if it was ugly.
An alternative idea: alpm_list_find_node, which returns with an alpm_list_t node, not the ->data; and reimplement alpm_list_remove_node, but with two param list (head) and node. This information is enough to cleanly remove that node, and can be cut from the current list_remove (by splitting that function).
Since performance doesn't apply here (this code is just used by -Ru, and should not be run an insane amount of times), then I prefer clean code here. Anyway, I think we have many other more important things to worry about.
Idézés Xavier
Nagy Gabor wrote:
Nagy Gabor wrote:
commit f43805d875ad5c672afbbfff48bded2087204773 Author: Chantry Xavier
Date: Sat May 10 18:47:42 2008 +0200 Cleanup usages of alpm_list_find and alpm_list_remove.
* remove obsolete and unused *_cmp helper functions like deppkg_cmp and _alpm_grp_cmp
* new alpm_list_remove_str function, used 6 times in handle.c
* remove _alpm_prov_cmp / _alpm_db_whatprovides and replace them by a more general alpm_find_pkg_satisfiers with a cleaner implementation. before: alpm_db_whatprovides(db, targ) after: alpm_find_pkg_satisfiers(alpm_db_getpkgcache(db), targ) Warning: pkg literal also satisfies pkg. But in most cases we called what_provides if we didn't find a literal.
Yes, there is no problem with this (I just emphasized it). I like the new function better because I think find_satisfiers is quite a common task. Btw, as I see, after this patch pacman -S 'kernel26>=2.6.24' automagically works, which is cool imho.
I am glad you liked at least one thing about my patch :)
If we like this then we could document it. But unfortunately in case of versioned dependencies the "literal first" rule disappear. We need something similar to "search for satisfier part" of resolvedeps. Maybe we could move that part to its own function and somehow use it. Bye P.S.: Sorry for "chit-chat", this is my last year in uni (hopefully;), I'm quite busy now. But in summer holiday patch flood will come... ;-) ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
participants (3)
-
Dan McGee
-
Nagy Gabor
-
Xavier