[pacman-dev] transaction flags

[Nagy Gabor]

> > 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