[pacman-dev] pmtransconv_t + cb_trans_conv
Hi! Some background: FS#7524 and http://bbs.archlinux.org/viewtopic.php?id=42959 So I decided to rephrase our questions and messages to give more information about what happening "inside". Then I soon ran into the question: "Is pmtransconv_t needed?". Why do we restrict ourselves to some pre-defined questions? The question string [char *] should also work, and then the front-end could put a " [Y/n]" after the question (or add yes/no buttons in a graphic dialog box). But after looking into cb_trans_conv I got the answer: the front-end must know the "meaning" of the question to apply its --no-confirm or (removed) --ask rules. I also saw in the comment, that function is tagged as ugly. My compromise: let the backend formulate the question (snprintf + pass char* question param or by using va_list) and keep this pmtransconv_t. An example: PM_TRANS_CONV_CONFLICT_PKG: "foo [pulled dependency] conflicts with bar. Do you remove bar?" Or we could use a more general PM_TRANS_CONV_REMOVE_LOCAL type... Opinions, ideas? Bye
On Jan 31, 2008 12:46 AM, Nagy Gabor
Hi!
Some background: FS#7524 and http://bbs.archlinux.org/viewtopic.php?id=42959 So I decided to rephrase our questions and messages to give more information about what happening "inside".
Then I soon ran into the question: "Is pmtransconv_t needed?". Why do we restrict ourselves to some pre-defined questions? The question string [char *] should also work, and then the front-end could put a " [Y/n]" after the question (or add yes/no buttons in a graphic dialog box). But after looking into cb_trans_conv I got the answer: the front-end must know the "meaning" of the question to apply its --no-confirm or (removed) --ask rules. I also saw in the comment, that function is tagged as ugly. My compromise: let the backend formulate the question (snprintf + pass char* question param or by using va_list) and keep this pmtransconv_t.
An example: PM_TRANS_CONV_CONFLICT_PKG: "foo [pulled dependency] conflicts with bar. Do you remove bar?" Or we could use a more general PM_TRANS_CONV_REMOVE_LOCAL type...
Opinions, ideas?
My opinion is that the backend should not have questions at all. All of the backend functions which need this sort of stuff to function should be redesigned and the questions moved to the front end.
My opinion is that the backend should not have questions at all. All of the backend functions which need this sort of stuff to function should be redesigned and the questions moved to the front end.
Well, imho this is an utopian idea. I haven't a clue, how we could do this in case of resolvedeps for example (without moving this function to front-end, losing flexibility or radically decreasing speed). Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/
2008/2/5 Nagy Gabor
My opinion is that the backend should not have questions at all. All of the backend functions which need this sort of stuff to function should be redesigned and the questions moved to the front end.
Well, imho this is an utopian idea. I haven't a clue, how we could do this in case of resolvedeps for example (without moving this function to front-end, losing flexibility or radically decreasing speed).
It's actually fairly simple, and just requires rethinking of the process as a whole. resolve-deps is the only reason moving questions out of the backend is difficult. Dan and I have already talked about this a little over email. I just need to sit down and code it up
participants (2)
-
Aaron Griffin
-
Nagy Gabor