OK. I've never heart complaints against -Rd and -Sd; they are the real database and system breakers. But they are optional, nobody said, that you must use any of them. The same for --nonew. And using it is _my_ responsibility, not the package manager's. [Btw, my philosophy: If I'm not allowed to break my system, then my freedom is restricted (or I am treated like a child);-)] This was a FR, and personally I find it also useful. I don't see why this is so dangerous (I mean it worth not to suffice some needs, while there are no regressions to others). [Btw, I think this patch ugly because of patching back-end instead of the front-end, not because of its philosophy]. I don't think, anyone can convince me about the (assumed) fact that this feature is bad, so I let the decision to Dan (as always). Technical discussion are welcome of course.
Well personally, I don't like Rd and Sd :) But you have a valid point, and that's also why I was never 100 % against your patch (even if I maybe made it sound like it :)). If we want to give more power to users, and then its their jobs to not do stupid things with it, then your patch is perfectly fine.
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". Bye