On Fri, Mar 07, 2008 at 08:57:55PM +0100, Nagy Gabor wrote:
Good. Now let's the technical discussion come;-) To be honest, I don't really like the way this patch works. I did this, because this was the easier (and I'm lazy ;-) and I followed the --needed option way. But in both cases the target filtering can be done in the front-end (and this would be nicer imho). However, this would be a bit duplicated work (and not notable slow-down), if we scanned for local version(number) in the front-end too. And it is a bit strange, that we pull a package with addtarget, and some targets are silently filtered out... In both cases only addtarget are affected. So the question is: shouldn't we move some options to front-end? Contras: -possible duplication in multiple front-ends -config->flags |= PM_TRANS_FLAG_NEEDED schema is the easiest we can imagine, thus put all work to the back-end Pros: -imho these stuffs fit clearly in front-end -we should(?) fit in 32 bits of flags ;-)
IMHO the main reason that these hurt my taste ;-) In the two mentioned option (--needed and possible --nonew <- terrible name), we could also add a filter option (flag?!;-) to addtarget only, because these are not transaction level stuffs, just "addtarget filters".
You might be right, using trans flags everywhere might not be a good idea. I am not sure how nice it will be to implement in the frontend though.