[pacman-dev] [PATCH 4/5] Versioned provisions
This patch introduces versioned provisions in "provision 1.0-1" format.
_alpm_db_whatprovides was modified accordingly (added sync500.py)
alpm_depcmp was modified accordingly (add043.py passes now; added add044.py and add045.py)
Note: alpm_db_search now uses the whole versioned %PROVIDES% string in its search
Note: debug logging was simplified in alpm_depcmp
Signed-off-by: Nagy Gabor
On Nov 17, 2007 7:51 AM, Nagy Gabor
This patch introduces versioned provisions in "provision 1.0-1" format. _alpm_db_whatprovides was modified accordingly (added sync500.py) alpm_depcmp was modified accordingly (add043.py passes now; added add044.py and add045.py) Note: alpm_db_search now uses the whole versioned %PROVIDES% string in its search Note: debug logging was simplified in alpm_depcmp
int SYMEXPORT alpm_depcmp(pmpkg_t *pkg, pmdepend_t *dep) { - int equal = 0; + alpm_list_t *i;
ALPM_LOG_FUNC;
const char *pkgname = alpm_pkg_get_name(pkg); - const char *pkgversion = alpm_pkg_get_version(pkg); + const char *pkgver = alpm_pkg_get_version(pkg); + int satisfy = 0;
- if(strcmp(pkgname, dep->name) == 0 - || alpm_list_find_str(alpm_pkg_get_provides(pkg), dep->name)) { + /* check (pkg->name, pkg->version) */ + satisfy = (!strcmp(pkgname, dep->name)
== 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
+ && dep_vercmp(pkgver, dep->mod, dep->version));
- equal = dep_vercmp(pkgversion, dep->mod, dep->version); + /* check provisions, format : "name version" */ + for(i = alpm_pkg_get_provides(pkg); i && !satisfy; i = i->next) { + char *provname = strdup(i->data); + char *provver = strchr(provname, ' ');
- char *mod = "~="; - switch(dep->mod) { - case PM_DEP_MOD_EQ: mod = "=="; break; - case PM_DEP_MOD_GE: mod = ">="; break; - case PM_DEP_MOD_LE: mod = "<="; break; - default: break; - } - - if(strlen(dep->version) > 0) { - _alpm_log(PM_LOG_DEBUG, "depcmp: %s-%s %s %s-%s => %s\n", - pkgname, pkgversion, - mod, dep->name, dep->version, (equal ? "match" : "no match")); + if(provver == NULL) { /* no provision version */ + satisfy = (dep->mod == PM_DEP_MOD_ANY + && !strcmp(provname, dep->name)); } else { - _alpm_log(PM_LOG_DEBUG, "depcmp: %s-%s %s %s => %s\n", - pkgname, pkgversion, - mod, dep->name, (equal ? "match" : "no match")); + *provver = '\0'; + provver += 1; This is ugly, and I won't take it again without at least a one line comment describing what is being done.
+ satisfy = (!strcmp(provname, dep->name) + && dep_vercmp(provver, dep->mod, dep->version)); } + free(provname); }
- return(equal); + char *depstring = alpm_dep_get_string(dep); + _alpm_log(PM_LOG_DEBUG, "alpm_depcmp %s-%s %s : %smatch\n", + pkgname, pkgver, depstring, satisfy ? "" : "no "); No need for tricks here to save 5 characters with the match/no match stuff. Code should be easily decipherable!
+ free(depstring); + return(satisfy); }
Looks good besides that. I'm pulling it into my tree. -Dan
On Nov 18, 2007 8:06 PM, Dan McGee
== 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
On Mon, Nov 19, 2007 at 12:13:14PM -0600, Aaron Griffin wrote:
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
Thank you for bringing this up again, I already forgot. That's exactly what I wanted to say : if patches are going to be rejected for a code style reason, then all these reasons should be written somewhere. I don't see what other places to look at, all other coding guidelines are in HACKING, and I can't find any mention of strcmp. Also, this rule only applies to strcmp? Because it returns 0 in case of success? And I just grepped the source for strcmp, it seems like it isn't used with == or != in the majority of the cases. Even though there are also many cases where it is. Note that I don't have any problem with coding guidelines, as long as they are clear and written. I'm all for a consistent style.
On Nov 19, 2007 12:34 PM, Xavier
On Mon, Nov 19, 2007 at 12:13:14PM -0600, Aaron Griffin wrote:
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
Thank you for bringing this up again, I already forgot. That's exactly what I wanted to say : if patches are going to be rejected for a code style reason, then all these reasons should be written somewhere. I don't see what other places to look at, all other coding guidelines are in HACKING, and I can't find any mention of strcmp.
Also, this rule only applies to strcmp? Because it returns 0 in case of success? And I just grepped the source for strcmp, it seems like it isn't used with == or != in the majority of the cases. Even though there are also many cases where it is.
Note that I don't have any problem with coding guidelines, as long as they are clear and written. I'm all for a consistent style.
OK, I will put this on my TODO list and get it into the GIT repo- I think it makes more sense and we can all refer to it there. I will also add some of these "unwritten rules". I'll even post it here first to see if their are any objections. http://www.archlinux.org/~aaron/pacman-coding.html -Dan
On Nov 19, 2007 12:59 PM, Dan McGee
On Nov 19, 2007 12:34 PM, Xavier
wrote: On Mon, Nov 19, 2007 at 12:13:14PM -0600, Aaron Griffin wrote:
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
Thank you for bringing this up again, I already forgot. That's exactly what I wanted to say : if patches are going to be rejected for a code style reason, then all these reasons should be written somewhere. I don't see what other places to look at, all other coding guidelines are in HACKING, and I can't find any mention of strcmp.
Also, this rule only applies to strcmp? Because it returns 0 in case of success? And I just grepped the source for strcmp, it seems like it isn't used with == or != in the majority of the cases. Even though there are also many cases where it is.
Note that I don't have any problem with coding guidelines, as long as they are clear and written. I'm all for a consistent style.
OK, I will put this on my TODO list and get it into the GIT repo- I think it makes more sense and we can all refer to it there. I will also add some of these "unwritten rules". I'll even post it here first to see if their are any objections.
I thought there was a better version of this somewhere. Either way, the pseudo-rule was something to the effect of: if(!strcmp(a,b)) { /* success case */ } This is bad because it just doesn't read right. You're using a negative to check for a success case. The compiler is going to do the same thing regardless, so why not make this readable: if(strcmp(a,b) == 0) { /* success case */ } Dan, feel free to disagree with me on this one
On Nov 19, 2007 2:00 PM, Aaron Griffin
On Nov 19, 2007 12:59 PM, Dan McGee
wrote: On Nov 19, 2007 12:34 PM, Xavier
wrote: On Mon, Nov 19, 2007 at 12:13:14PM -0600, Aaron Griffin wrote:
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
Thank you for bringing this up again, I already forgot. That's exactly what I wanted to say : if patches are going to be rejected for a code style reason, then all these reasons should be written somewhere. I don't see what other places to look at, all other coding guidelines are in HACKING, and I can't find any mention of strcmp.
Also, this rule only applies to strcmp? Because it returns 0 in case of success? And I just grepped the source for strcmp, it seems like it isn't used with == or != in the majority of the cases. Even though there are also many cases where it is.
Note that I don't have any problem with coding guidelines, as long as they are clear and written. I'm all for a consistent style.
OK, I will put this on my TODO list and get it into the GIT repo- I think it makes more sense and we can all refer to it there. I will also add some of these "unwritten rules". I'll even post it here first to see if their are any objections.
I thought there was a better version of this somewhere.
Either way, the pseudo-rule was something to the effect of:
if(!strcmp(a,b)) { /* success case */ }
This is bad because it just doesn't read right. You're using a negative to check for a success case. The compiler is going to do the same thing regardless, so why not make this readable:
if(strcmp(a,b) == 0) { /* success case */ }
Dan, feel free to disagree with me on this one
Dude, you quoted me agreeing, thats how the whole debate started. :)
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
-Dan
On Nov 19, 2007 2:35 PM, Dan McGee
On Nov 19, 2007 2:00 PM, Aaron Griffin
wrote: On Nov 19, 2007 12:59 PM, Dan McGee
wrote: On Nov 19, 2007 12:34 PM, Xavier
wrote: On Mon, Nov 19, 2007 at 12:13:14PM -0600, Aaron Griffin wrote:
On Nov 18, 2007 8:06 PM, Dan McGee
wrote: == 0 is much clearer, so I'm going to change this back if I pull the patch. Let's not take shortcuts in C just because they work- lets make the code readable for everyone. It will all get compiled the same way anyway. As a general rule, I always want to see an == or != used with strcmp- it is just easier to digest.
This is also in the pacman coding guidelines somewhere, for the record.
Thank you for bringing this up again, I already forgot. That's exactly what I wanted to say : if patches are going to be rejected for a code style reason, then all these reasons should be written somewhere. I don't see what other places to look at, all other coding guidelines are in HACKING, and I can't find any mention of strcmp.
Also, this rule only applies to strcmp? Because it returns 0 in case of success? And I just grepped the source for strcmp, it seems like it isn't used with == or != in the majority of the cases. Even though there are also many cases where it is.
Note that I don't have any problem with coding guidelines, as long as they are clear and written. I'm all for a consistent style.
OK, I will put this on my TODO list and get it into the GIT repo- I think it makes more sense and we can all refer to it there. I will also add some of these "unwritten rules". I'll even post it here first to see if their are any objections.
I thought there was a better version of this somewhere.
Either way, the pseudo-rule was something to the effect of:
if(!strcmp(a,b)) { /* success case */ }
This is bad because it just doesn't read right. You're using a negative to check for a success case. The compiler is going to do the same thing regardless, so why not make this readable:
if(strcmp(a,b) == 0) { /* success case */ }
Dan, feel free to disagree with me on this one
Dude, you quoted me agreeing, thats how the whole debate started. :)
I meant on the explanation 8)
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor
-
Xavier