[pacman-dev] %REPLACES% doesn't appear in localdb
Hi! See _alpm_db_write in libalpm/be_files.c: ------------------------- 702 if(!local) { 703 if(info->replaces) { 704 fputs("%REPLACES%\n", fp); 705 for(lp = info->replaces; lp; lp = lp->next) { 706 fprintf(fp, "%s\n", (char *)lp->data); 707 } 708 fprintf(fp, "\n"); 709 } -------------------------- So %REPLACES% field is not recorded to local db. I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local) line instead. Anyway, is there any case where local != 0? Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Anyway, is there any case where local != 0? edit: local == 0.
Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Jan 3, 2008 7:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local) line instead.
I wondered about the same thing for a while. I see no reason to keep it out of the local DB, it's rarely used anyway. Dan?
2008/1/3, Aaron Griffin <aaronmgriffin@gmail.com>:
On Jan 3, 2008 7:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local) line instead.
I wondered about the same thing for a while.
I see no reason to keep it out of the local DB, it's rarely used anyway. Dan?
Status on this? I couldn't found anything about this in git log. -- Roman Kyrylych (Роман Кирилич)
On Jan 8, 2008 5:30 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/1/3, Aaron Griffin <aaronmgriffin@gmail.com>:
On Jan 3, 2008 7:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local) line instead.
I wondered about the same thing for a while.
I see no reason to keep it out of the local DB, it's rarely used anyway. Dan?
Status on this? I couldn't found anything about this in git log.
I want to wait until 3.1.1 so it can get sufficient testing. Although I think the exclusion is weird, I'm not sure how our code will handle it on complicated upgrades as no one has produced a pactest yet to test such things. -Dan
Idézés Dan McGee <dpmcgee@gmail.com>:
2008/1/3, Aaron Griffin <aaronmgriffin@gmail.com>:
On Jan 3, 2008 7:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local)
On Jan 8, 2008 5:30 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote: line instead.
I wondered about the same thing for a while.
I see no reason to keep it out of the local DB, it's rarely used anyway.
Dan?
Status on this? I couldn't found anything about this in git log.
I want to wait until 3.1.1 so it can get sufficient testing. Although I think the exclusion is weird, I'm not sure how our code will handle it on complicated upgrades as no one has produced a pactest yet to test such things.
-Dan
We don't want to exclude it, we want to add it to localdb instead. Since %REPLACES% is not there now, it will be just an extra unused but informative(?) field like %PACKAGER%. I wanted to exclude it from -Qi listing only, if you choose not to store the %REPLACES% information in localdb (because then we always get "Replaces: None" false report, like now). Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Jan 9, 2008 6:22 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Idézés Dan McGee <dpmcgee@gmail.com>:
2008/1/3, Aaron Griffin <aaronmgriffin@gmail.com>:
On Jan 3, 2008 7:46 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I know, that we don't need that field, but then we should remove 'replaces' listing from -Qi. Since we have some other not needed but interesting infos in local db (packager, optdepend etc.) I vote for remove that if(!local)
On Jan 8, 2008 5:30 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote: line instead.
I wondered about the same thing for a while.
I see no reason to keep it out of the local DB, it's rarely used anyway.
Dan?
Status on this? I couldn't found anything about this in git log.
I want to wait until 3.1.1 so it can get sufficient testing. Although I think the exclusion is weird, I'm not sure how our code will handle it on complicated upgrades as no one has produced a pactest yet to test such things.
We don't want to exclude it, we want to add it to localdb instead. Um...thats exactly what I said. I just said it *needs testing*.
Since %REPLACES% is not there now, it will be just an extra unused but informative(?) field like %PACKAGER%. I wanted to exclude it from -Qi listing only, if you choose not to store the %REPLACES% information in localdb (because then we always get "Replaces: None" false report, like now). So my point still stands. Do you know for a fact that having a non-empty replaces list for a local package will not affect conflict and dependency resolving? Until you have proved this, I don't feel comfortable making the change.
-Dan
Dan McGee wrote:
So my point still stands. Do you know for a fact that having a non-empty replaces list for a local package will not affect conflict and dependency resolving? Until you have proved this, I don't feel comfortable making the change.
grep -r get_replaces lib/libalpm/*.c
I have to admit I was also a bit confused by the whole discussion, but didn't speak up because it looked like a minor problem. To answer your question, it's actually rather easy. get_replaces is really just used once, and that is in find_replacements. find_replacements is only used for the -Su operation, and has 0 effect on conflict and dependency resolving. lib/libalpm/package.c: alpm_list_t SYMEXPORT *alpm_pkg_get_replaces(pmpkg_t *pkg) lib/libalpm/package.c: newpkg->replaces = alpm_list_strdup(alpm_pkg_get_replaces(pkg)); lib/libalpm/sync.c: for(k = alpm_pkg_get_replaces(spkg); k; k = k->next) { And it's called on spkg, so a sync pkg, in a sync database.
On Jan 9, 2008 9:40 AM, Xavier <shiningxc@gmail.com> wrote:
Dan McGee wrote:
So my point still stands. Do you know for a fact that having a non-empty replaces list for a local package will not affect conflict and dependency resolving? Until you have proved this, I don't feel comfortable making the change.
I have to admit I was also a bit confused by the whole discussion, but didn't speak up because it looked like a minor problem.
To answer your question, it's actually rather easy. get_replaces is really just used once, and that is in find_replacements. find_replacements is only used for the -Su operation, and has 0 effect on conflict and dependency resolving.
grep -r get_replaces lib/libalpm/*.c lib/libalpm/package.c: alpm_list_t SYMEXPORT *alpm_pkg_get_replaces(pmpkg_t *pkg) lib/libalpm/package.c: newpkg->replaces = alpm_list_strdup(alpm_pkg_get_replaces(pkg)); lib/libalpm/sync.c: for(k = alpm_pkg_get_replaces(spkg); k; k = k->next) {
And it's called on spkg, so a sync pkg, in a sync database.
Patches welcome from anyone, this shouldn't be a hard fix. Thanks for looking into the details, Xavier. -Dan
On Jan 9, 2008 6:10 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Jan 9, 2008 9:40 AM, Xavier <shiningxc@gmail.com> wrote:
Dan McGee wrote:
So my point still stands. Do you know for a fact that having a non-empty replaces list for a local package will not affect conflict and dependency resolving? Until you have proved this, I don't feel comfortable making the change.
I have to admit I was also a bit confused by the whole discussion, but didn't speak up because it looked like a minor problem.
To answer your question, it's actually rather easy. get_replaces is really just used once, and that is in find_replacements. find_replacements is only used for the -Su operation, and has 0 effect on conflict and dependency resolving.
grep -r get_replaces lib/libalpm/*.c lib/libalpm/package.c: alpm_list_t SYMEXPORT *alpm_pkg_get_replaces(pmpkg_t *pkg) lib/libalpm/package.c: newpkg->replaces = alpm_list_strdup(alpm_pkg_get_replaces(pkg)); lib/libalpm/sync.c: for(k = alpm_pkg_get_replaces(spkg); k; k = k->next) {
And it's called on spkg, so a sync pkg, in a sync database.
Patches welcome from anyone, this shouldn't be a hard fix. Thanks for looking into the details, Xavier.
Bam? http://code.phraktured.net/?p=pacman.git;a=shortlog;h=woot
On Jan 9, 2008 6:24 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Jan 9, 2008 6:10 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Jan 9, 2008 9:40 AM, Xavier <shiningxc@gmail.com> wrote:
Dan McGee wrote:
So my point still stands. Do you know for a fact that having a non-empty replaces list for a local package will not affect conflict and dependency resolving? Until you have proved this, I don't feel comfortable making the change.
I have to admit I was also a bit confused by the whole discussion, but didn't speak up because it looked like a minor problem.
To answer your question, it's actually rather easy. get_replaces is really just used once, and that is in find_replacements. find_replacements is only used for the -Su operation, and has 0 effect on conflict and dependency resolving.
grep -r get_replaces lib/libalpm/*.c lib/libalpm/package.c: alpm_list_t SYMEXPORT *alpm_pkg_get_replaces(pmpkg_t *pkg) lib/libalpm/package.c: newpkg->replaces = alpm_list_strdup(alpm_pkg_get_replaces(pkg)); lib/libalpm/sync.c: for(k = alpm_pkg_get_replaces(spkg); k; k = k->next) {
And it's called on spkg, so a sync pkg, in a sync database.
Patches welcome from anyone, this shouldn't be a hard fix. Thanks for looking into the details, Xavier.
Bam? http://code.phraktured.net/?p=pacman.git;a=shortlog;h=woot
409 /* the REPLACES tag is special -- it only appears in sync repositories, 410 * not the local one. */ ^^ We should probably get rid of that misleading comment too. And why we are at it, any reason not to store that FORCE tag too? It seems like it could be useful information (knowing that this package was force-sysupgraded). If we do that, then we don't have any if(local) constructs left. -Dan
participants (5)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor
-
Roman Kyrylych
-
Xavier