Hi! First of all, many thanks to Xavier for this cool stuff. Some suggestions/feature requests: -you don't free() anything in testpkg.c; this is not a big problem, but rigorous c-programmers frees everything in even helloworld.c;-) -conflict checking also would be nice and easy to implement -a small speedup suggestion (however, speed is not important here): line 176: data = alpm_checkdeps(db, PM_TRANS_TYPE_ADD, alpm_db_getpkgcache(db)); here you could use a fake_empty_db as a first parameter: -O(n^2) operation -my biggest feature request: an option to fix the problems instead of just listing them (at least rewrite wrong requiredby fields, and a suggestion "pacman -S --asdeps [missingdeps]") I will share my results with you, this is a nice database-breaker-bug history: -testdb found many duplicated requiredby fields; I had to fix them with db-fix.sh + re-pacman + pacman -U (I have no net at home at the moment; see my biggest feature request ;-) -testdb found 4 other wrong requiredby fields (however, extra requiredby field doesn't cause an error now: see remove048.py): this is the category of the REMOVEUPGRADE transaction: requiredby004.py -and an other old bug (fixed): sysvinit needs awk, gawk provides awk; and sysvinit wasn't listed in requiredby field of gawk. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Thu, Oct 04, 2007 at 12:48:52PM +0200, Nagy Gabor wrote:
Hi! First of all, many thanks to Xavier for this cool stuff. Some suggestions/feature requests: -you don't free() anything in testpkg.c; this is not a big problem, but rigorous c-programmers frees everything in even helloworld.c;-) -conflict checking also would be nice and easy to implement -a small speedup suggestion (however, speed is not important here): line 176: data = alpm_checkdeps(db, PM_TRANS_TYPE_ADD, alpm_db_getpkgcache(db)); here you could use a fake_empty_db as a first parameter: -O(n^2) operation -my biggest feature request: an option to fix the problems instead of just listing them (at least rewrite wrong requiredby fields, and a suggestion "pacman -S --asdeps [missingdeps]")
Right, it can be improved, patches are welcome :)
I will share my results with you, this is a nice database-breaker-bug history: -testdb found many duplicated requiredby fields; I had to fix them with db-fix.sh + re-pacman + pacman -U (I have no net at home at the moment; see my biggest feature request ;-)
You can just do : pacman -S <broken packages> Required By fields are rebuilt when reinstalling packages.
-testdb found 4 other wrong requiredby fields (however, extra requiredby field doesn't cause an error now: see remove048.py): this is the category of the REMOVEUPGRADE transaction: requiredby004.py -and an other old bug (fixed): sysvinit needs awk, gawk provides awk; and sysvinit wasn't listed in requiredby field of gawk.
Right, my database had also many breakages :) I just reinstalled the affected packages, it's very quick and easy.
-you don't free() anything in testpkg.c; this is not a big problem, but rigorous c-programmers frees everything in even helloworld.c;-)
-conflict checking also would be nice and easy to implement
-a small speedup suggestion (however, speed is not important here): line 176: data = alpm_checkdeps(db, PM_TRANS_TYPE_ADD, alpm_db_getpkgcache(db)); here you could use a fake_empty_db as a first parameter: -O(n^2) operation cannot implement easily, because db->pkgcache == NULL doesn't mean empty
Hi! Patch attached: the patch (hopefully) fixes them. this is also done; but TODO: I did a dirty hack to make check_conflict visible from testdb.c (I'm not familiar in these static/symexport... stuffs, check_conflict probably should be renamed, too) pkgcache (this means pkgcache is not loaded, and induces a reload); [int pkgcache_loaded entry in pmdb_t would be helpful here]
-my biggest feature request: an option to fix the problems instead of just listing them (at least rewrite wrong requiredby fields, and a suggestion "pacman -S --asdeps [missingdeps]") Later...
Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Mon, Oct 08, 2007 at 04:37:50PM +0200, Nagy Gabor wrote:
this is also done; but TODO: I did a dirty hack to make check_conflict visible from testdb.c (I'm not familiar in these static/symexport... stuffs, check_conflict probably should be renamed, too)
I don't know really how the interfaces for the conflict checks should be. Currently we have these 2 functions : * void check_conflict(alpm_list_t *list1, alpm_list_t *list2, alpm_list_t **baddeps, int order) * alpm_list_t *_alpm_checkconflicts(pmdb_t *db, alpm_list_t *packages) built on top of check_conflict. And _alpm_checkconflicts is used in sync.c and add.c . Though, after your resolve conflict patch (not merged), _alpm_checkconflicts is no longer used in sync.c . Instead, check_conflict is used directly. And now, for testdb too, check_conflict has to be used directly. So it appears that the _alpm_checkconflicts function isn't really useful. However, the interface of check_conflict is too confusing for a public function imo. I don't know what should be done really, this requires some thinking. And anyway, you said these conflict checks sucked because of the assymetrical storing (I don't know how that should be handled either..). About static/symexport stuff, first a part of the README file : 27 In a general manner, public library functions are named "alpm_<type>_<action>" 28 (examples: alpm_trans_commit(), alpm_release(), alpm_pkg_getinfo(), ...). 29 Internal (and thus private) functions should be named "_alpm_XXX" for instance 30 (examples: _alpm_needbackup(), _alpm_runscriplet(), ...). Functions defined and 31 used inside a single file should be defined as "static". So, if I undestood correctly, you could have : 1) void SYMEXPORT alpm_conflict_check defined in conflict.c and declared in alpm.h (public) 2) void _alpm_conflict_check defined in conflict.c and declared in conflict.h (internal) 3) static void conflict_check defined in conflict.c (only used in conflict.c) And the three could exist in the same time (1 and 2 in the same time is very common in libalpm).
On Mon, Oct 08, 2007 at 04:37:50PM +0200, Nagy Gabor wrote:
this is also done; but TODO: I did a dirty hack to make check_conflict visible from testdb.c (I'm not familiar in these static/symexport... stuffs, check_conflict probably should be renamed, too)
I don't know really how the interfaces for the conflict checks should be. Currently we have these 2 functions : * void check_conflict(alpm_list_t *list1, alpm_list_t *list2, alpm_list_t **baddeps, int order)
* alpm_list_t *_alpm_checkconflicts(pmdb_t *db, alpm_list_t *packages) built on top of check_conflict.
And _alpm_checkconflicts is used in sync.c and add.c . Though, after your resolve conflict patch (not merged), _alpm_checkconflicts is no longer used in sync.c . Instead, check_conflict is used directly. And now, for testdb too, check_conflict has to be used directly.
So it appears that the _alpm_checkconflicts function isn't really useful. However, the interface of check_conflict is too confusing for a public function imo. I don't know what should be done really, this requires some thinking.
I'm on the same opinion; this is an other reason for the dirty hack. But you can see that direct using of check_conflict is reasonable in many cases, so I suggest you to provide both a beginner public funtion (alpm_checkconflicts) and an advanced one (check_conflict). Or you can also choose does_conflict instead of check_conflict as an atomic conflict-compare function (analogue of alpm_depcmp), but this may lead to many duplicated codes (like alpm_depcmp ;-)
And anyway, you said these conflict checks sucked because of the assymetrical storing (I don't know how that should be handled either..).
IMHO the most cleaner would be a new pmconflict_t type, because using pmdepmissing_t confuses me often; and we can treat the two conflicting packages as sets (unordered pairs). An other possible solution: check_conflict (or add_conflict) should do the asymmetric check at least in a special order == case [before adding a (p,q) conflict pair it should check if (p,q) or (q,p) has been already added to the list.
About static/symexport stuff, first a part of the README file :
27 In a general manner, public library functions are named "alpm_<type>_<action>" 28 (examples: alpm_trans_commit(), alpm_release(), alpm_pkg_getinfo(), ...). 29 Internal (and thus private) functions should be named "_alpm_XXX" for instance 30 (examples: _alpm_needbackup(), _alpm_runscriplet(), ...). Functions defined and 31 used inside a single file should be defined as "static".
So, if I undestood correctly, you could have : 1) void SYMEXPORT alpm_conflict_check defined in conflict.c and declared in alpm.h (public) 2) void _alpm_conflict_check defined in conflict.c and declared in conflict.h (internal) 3) static void conflict_check defined in conflict.c (only used in conflict.c)
And the three could exist in the same time (1 and 2 in the same time is very common in libalpm). Thx for this useful info.
Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Hi! I had to rewrite the patch, because I found a new bug in testdb.c: Using alpm_list_msort broke requiredby lists in pkgcache (you can test this by duplicating the requiredby-test code), so I fixed this, too. Patch attached, bye. ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On 10/9/07, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Hi! I had to rewrite the patch, because I found a new bug in testdb.c: Using alpm_list_msort broke requiredby lists in pkgcache (you can test this by duplicating the requiredby-test code), so I fixed this, too. Patch attached, bye.
Great! Thanks a lot for the patch - this looks good to me. My only qualm is that we've set the precedent of using _alpm_* for internal functions, so check_conflict should probably use the same prefix. Dan?
On 10/9/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 10/9/07, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
Hi! I had to rewrite the patch, because I found a new bug in testdb.c: Using alpm_list_msort broke requiredby lists in pkgcache (you can test this by duplicating the requiredby-test code), so I fixed this, too. Patch attached, bye.
Great! Thanks a lot for the patch - this looks good to me.
My only qualm is that we've set the precedent of using _alpm_* for internal functions, so check_conflict should probably use the same prefix.
Dan?
Um, bigger problems here. 1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory. 2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.) 3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility. 4. FREELIST? libalpm private function. Sorry to burst anyone's hopes here, but this patch just isn't acceptable right now. -Dan
On Wed, Oct 10, 2007 at 07:00:15AM -0500, Dan McGee wrote:
Um, bigger problems here.
1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory.
3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility.
Indeed, I already tried to explain that in my reply to the first version of this patch.
2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.)
Oops, my mistake, copy/paste issue indeed :) But I also noticed I didn't follow the prefix rules in some of my earlier patches, when I hadn't understood them fully yet :P
4. FREELIST? libalpm private function.
Ah right, I didn't notice this.
Um, bigger problems here.
1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory. Well, I wrote in my first e-mail in this thread that I wasn't familiar in these alpm public/private/whatever and naming conventions, so I wanted to let you clean-up this part (I hoped, that the patch is helpful with this glitch, too). And you are the "leader", you should choose the right conflict-checker funtion to be public, and give them a good name (alpm_*). See also: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009549.html 2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.) This is in git already. 3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility. See 1. 4. FREELIST? libalpm private function. I don't understand this (anyway, that is a macro). "#include <alpm_list.h>" is not allowed (this is in git/testdb.c already)? Then how should be work with alpm_lists? Sorry to burst anyone's hopes here, but this patch just isn't acceptable right now. OK, but keep your eyes on the remaining bugs in testdb.c.
Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
Um, bigger problems here.
1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory. Well, I wrote in my first e-mail in this thread that I wasn't familiar in these alpm public/private/whatever and naming conventions, so I wanted to let you clean-up this part (I hoped, that the patch is helpful with this glitch, too). And you are the "leader", you should choose the right conflict-checker funtion to be public, and give them a good name (alpm_*). See also: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009549.html 2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.) This is in git already. 3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility. See 1. 4. FREELIST? libalpm private function. I don't understand this (anyway, that is a macro). "#include <alpm_list.h>" is not allowed (this is in git/testdb.c already)? Then how should be work with alpm_lists? Sorry to burst anyone's hopes here, but this patch just isn't acceptable right now. OK, but keep your eyes on the remaining bugs in testdb.c.
OK. I try to explain what my problem is: If I send a patch, I have the feeling that it will be committed without modification or rejected. But this is a teamwork, so you can improve/fix my patch before commit. I don't care if you modify my patch, I don't care if my name is not listed as patch-author etc.; I suppose that before committing all accepted patch is carefully read, so fixing/improving is not an extra work IMHO, so I suggest to do that. For example, there are parts in my big checkdeps/alpm_sync_prepare patches which I don't like (the 2in1 remove+upgrade list loop for example); but that parts are unimportant; and (1.) I trust on your creativity and (2.) I couldn't do it better. Back to the current patch: First of all, I'm not a programmer, so I have few experience in c-programming. And to tell the truth I was never interested in "programming language syntaxes", I'm interested in algorithmic problems instead. So I _knew_ that my patch is not perfect, but I hoped that it will be helpful (it points to some bugs and its concept is (hopefully) good.); but I also knew, that even a 5-year-old kid can fix it, if he knows C static/public/whatever syntax and alpm function-naming conversions. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Mon, Oct 15, 2007 at 01:30:05PM +0200, Nagy Gabor wrote:
OK. I try to explain what my problem is: If I send a patch, I have the feeling that it will be committed without modification or rejected. But this is a teamwork, so you can improve/fix my patch before commit. I don't care if you modify my patch, I don't care if my name is not listed as patch-author etc.; I suppose that before committing all accepted patch is carefully read, so fixing/improving is not an extra work IMHO, so I suggest to do that. For example, there are parts in my big checkdeps/alpm_sync_prepare patches which I don't like (the 2in1 remove+upgrade list loop for example); but that parts are unimportant; and (1.) I trust on your creativity and (2.) I couldn't do it better. Back to the current patch: First of all, I'm not a programmer, so I have few experience in c-programming.
I don't have any programming experience in C either (besides pacman). Maybe that's the problem. I didn't like much the 2in1 remove+upgrade list loop, and I think Dan didn't either. I tried a while ago to handle it in another way, but it was a dead end. And then I gave up..
And to tell the truth I was never interested in "programming language syntaxes", I'm interested in algorithmic problems instead. So I _knew_ that my patch is not perfect, but I hoped that it will be helpful (it points to some bugs and its concept is (hopefully) good.); but I also knew, that even a 5-year-old kid can fix it, if he knows C static/public/whatever syntax and alpm function-naming conversions.
If it was only the naming that was problematic, I would have fixed it. But there are other things that disturbed me. I already noted the conflict checking on my TODO list for testdb the first time you suggested it. I didn't do it yet for the reasons I already mentioned in this thread, that I am not satisfied with the current libalpm conflict checking interface. And also the asymetrical storing problem. For the other pkg->requiredby bug, I also replied, but AGAIN, I am clueless about what the correct fix is. My proposal was to duplicate the list before sorting it in testdb. I'm beginning to think that pacman was probably already a too complex project to start with, I always have to ask about how things should be done, and I'm very rarely able to come up with a patch I'm happy with. So I'm progressively losing the little motivation I had in the beginning. I also find it sad that pacman gets so little attention / is so short of manpower.
I'm beginning to think that pacman was probably already a too complex project to start with, I always have to ask about how things should be done, and I'm very rarely able to come up with a patch I'm happy with. So I'm progressively losing the little motivation I had in the beginning. I also find it sad that pacman gets so little attention / is so short of manpower. Please don't loose your motivation ;-) Yes, there are problems around pacman development; but as I said, sometimes Dan (or Aaron) is the bottleneck. As I see, you pay enough attention to pacman, this was a big motivation to me. If you decide to leave the project, probably I will do so. So I suggest the main devels to start to rethink the development philosophy (see also: pacman-g2 fork) <- I believe that you have few freetime, then find trusted/talented/enthusiastic new guys or start a real devel-branch (as I see, pacman-git is stable, only "trivial" things are committed) or dunno. Conclusion: I'm sure that pacman would get much more attention, but somehow the enthusiastic guys are bundled out. And then you can say that pacman is a dying project <- that is easy: the more attention the less freetime. Bye, ngaba
---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
On Mon, Oct 15, 2007 at 03:10:15PM +0200, Xavier <shiningxc@gmail.com> wrote:
I'm beginning to think that pacman was probably already a too complex project to start with, I always have to ask about how things should be done, and I'm very rarely able to come up with a patch I'm happy with.
well, pacman's code has a high quality i think. it has a homogenous style, the indentation is clean, etc. i started c programming on linux with MPlayer and.. well if you want to see ugly code then just have a look at mplayer.c :-) also - pacman is a small project. you can read it's full source during a single afternoon. most projects has a much wider codebase and you have to spent days just with reading the source (for example i recently wanted to hack bitlbee and i had to realize that i have to learn the whole glib event handling first.. - pacman does not use any such complex external lib, another reason for choosing pacman as your #1 c project :) ) - VMiklos
Um, bigger problems here.
1. We are including a private header outside of the library, a big no-no. Can't use conflict.h outside of the libalpm directory. Well, I wrote in my first e-mail in this thread that I wasn't familiar in these alpm public/private/whatever and naming conventions, so I wanted to let you clean-up this part (I hoped, that the patch is helpful with this glitch, too). And you are the "leader", you should choose the right conflict-checker funtion to be public, and give them a good name (alpm_*). See also: http://www.archlinux.org/pipermail/pacman-dev/2007-October/009549.html 2. We are using _alpm_str_cmp publicly (edit: I see now that it is defined in testdb.c. What was I thinking when I let that slip by? We shouldn't use the _alpm prefix anywhere. outside of the library, just a copy paste issue though.) This is in git already. 3. If we need check conflict to be public, it needs to be declared in alpm.h and have an alpm_ prefix. Aaron- not sure why you thought it should be private...it was static before. This is two jumps in visibility. See 1. 4. FREELIST? libalpm private function. I don't understand this (anyway, that is a macro). "#include <alpm_list.h>" is not allowed (this is in git/testdb.c already)? Then how should be work with alpm_lists? Sorry to burst anyone's hopes here, but this patch just isn't acceptable right now. OK, but keep your eyes on the remaining bugs in testdb.c.
Bye, ngaba I'm planning to rework the patch. I start to agree with VMiklos, who said that testdb should me merged to pacman. What's more, I'm saying testdb should me merged to libalpm: then almost all of the problems listed above would disappear. I would like to add one more argument: If you give a look at my reworked patch, you will notice that it directly modifies pkg->requiredby, which is an ugly thing: it should be done through libalpm api; however, libalpm has no alpm_pkg_set_requiredby or similar function <- that would be used rarely. So merging the whole testdb stuff to libalpm would eliminate the public/non-public argument and IMHO testdb can fit in libalpm. And pacman is the best front-end for testdb, IMHO (for programmers and users).
Any feedback appreciated, ngaba PS: So now it is not so important to implement a more powerful _public_ conflict checking function to libalpm. I would still prefer it.
On Fri, Oct 26, 2007 at 01:40:25PM +0200, Nagy Gabor wrote:
I'm planning to rework the patch. I start to agree with VMiklos, who said that testdb should me merged to pacman. What's more, I'm saying testdb should me merged to libalpm: then almost all of the problems listed above would disappear. I would like to add one more argument: If you give a look at my reworked patch, you will notice that it directly modifies pkg->requiredby, which is an ugly thing: it should be done through libalpm api; however, libalpm has no alpm_pkg_set_requiredby or similar function <- that would be used rarely. So merging the whole testdb stuff to libalpm would eliminate the public/non-public argument and IMHO testdb can fit in libalpm. And pacman is the best front-end for testdb, IMHO (for programmers and users).
Any feedback appreciated, ngaba
PS: So now it is not so important to implement a more powerful _public_ conflict checking function to libalpm. I would still prefer it.
Well, I asked back then where testdb would suit the best, and it seems like no one had a strong opinion. Seems like Dan thought an external tool was a good idea, so that's how I started writing it. Later vmiklos said he had a slight preference for keeping the stuff in libalpm. But I didn't find it enough to change it back. Hm, now I remember that Dan didn't like how the old -Qt option was written in libalpm, maybe because the lib shouldn't return the error/warning message as strings or list of strings. Or something in this spirit, I don't really remember..
On Fri, Oct 26, 2007 at 01:40:25PM +0200, Nagy Gabor wrote:
I'm planning to rework the patch. I start to agree with VMiklos, who said that testdb should me merged to pacman. What's more, I'm saying testdb should me merged to libalpm: then almost all of the problems listed above would disappear. I would like to add one more argument: If you give a look at my reworked patch, you will notice that it directly modifies pkg->requiredby, which is an ugly thing: it should be done through libalpm api; however, libalpm has no alpm_pkg_set_requiredby or similar function <- that would be used rarely. So merging the whole testdb stuff to libalpm would eliminate the public/non-public argument and IMHO testdb can fit in libalpm. And pacman is the best front-end for testdb, IMHO (for programmers and users).
Any feedback appreciated, ngaba
PS: So now it is not so important to implement a more powerful _public_ conflict checking function to libalpm. I would still prefer it.
Well, I asked back then where testdb would suit the best, and it seems like no one had a strong opinion. Seems like Dan thought an external tool was a good idea, so that's how I started writing it. Later vmiklos said he had a slight preference for keeping the stuff in libalpm. But I didn't find it enough to change it back. I said -Qtt (but probably that was too late);-): http://www.archlinux.org/pipermail/pacman-dev/2007-September/009252.html Hm, now I remember that Dan didn't like how the old -Qt option was written in libalpm, maybe because the lib shouldn't return the error/warning message as strings or list of strings. Or something in this spirit, I don't really remember.. Indeed, it shouldn't return with anything. It simply should use _alpm_log. Whatever we decide, these things should be fixed. But we should make a decision first. Then I (or Xavier? ;-) will implement it. As Xavier said, if we stay with the external testdb, we can create a copy of the requiredby lists and then sort that. (But that is needless, because sorted requiredby list doesn't hurt anything.) One more thing, that you won't like: If I hadn't read alpm_list_msort's source, then I wouldn't have found this bug, so at least the comment before alpm_list_msort should mention that it will sort the list "in place" and it won't create a new (sorted) list. Maybe I should know mergesort algorithm better ;-) Bye, ngaba
On Sat, Oct 27, 2007 at 04:44:31PM +0200, Xavier <shiningxc@gmail.com> wrote:
libalpm, maybe because the lib shouldn't return the error/warning message as strings or list of strings. Or something in this spirit, I don't really remember..
and who said the lib should return error/warning strings? enums could be used as well, just like with conversations - VMiklos
On Tue, Oct 09, 2007 at 11:55:47AM +0200, Nagy Gabor wrote:
Hi! I had to rewrite the patch, because I found a new bug in testdb.c: Using alpm_list_msort broke requiredby lists in pkgcache (you can test this by duplicating the requiredby-test code), so I fixed this, too. Patch attached, bye.
Oh, I see, what I did is pretty bad : I directly modified (sorted) the requiredby fields from each package.. Without updating the head of the list stored in pkg->requiredby. I don't think it's possible to edit pkg->requiredby anyway, but that might be a good thing. So the list should probably be copied first, before sorting it, right?
participants (5)
-
Aaron Griffin
-
Dan McGee
-
Miklos Vajna
-
Nagy Gabor
-
Xavier