Xavier wrote: > On Thu, Nov 12, 2009 at 2:08 PM, Cedric Staniewski <[email protected]> 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. > > In the best case, a wrapper will just forward it correctly. In the > worst case, it will break it.
Since pacman 3.3 it is not that hidden anymore[1]. [1] http://projects.archlinux.org/pacman.git/commit/?id=9af9c0f328094228fa363d842ddc9b2a605f0d22
