On Thu, Nov 12, 2009 at 7:48 AM, Xavier <shiningxc@gmail.com> wrote:
On Thu, Nov 12, 2009 at 2:08 PM, Cedric Staniewski <cedric@gmx.ca> wrote:
I have been thinking about this and its companion patch. I like the refactoring of the pacman call into the function but dislike not replacing the "pacman -T" call with it.
If there is a config option for setting the "pacman" binary, and I have program that replaces pacman (e.g. the one based on the python alpm wrapper should work), then I should not need pacman on my system at all.
So I prefer the original version where the "pacman -T" call was replaced too.
And leave it to the pacman wrapper authors to fix their programs? Sounds good. :) I also prefer the original patch, mainly because it seems 'cleaner' to me, but being able to replace pacman completely on a system is a valid reason, too.
Well, I am still not convinced. Why would any wrapper have to care about pacman -T ? This is a hidden / undocumented / internal argument just for the usage of makepkg.
Doesn't look undocumented to me: -T, --deptest Check dependencies; this is useful in scripts such as makepkg to check installed packages. This operation will check each dependency specified and return a list of those which are not currently satisfied on the system. This operation accepts no other options. Example usage: pacman -T qt "bash>=3.2".
In the best case, a wrapper will just forward it correctly. In the worst case, it will break it.