Miklos Vajna wrote:
just do a -Q, save it, do a -Q after the build, diff the two list and remove the difference. so that if you did -S mta, you'll get postfix in the diff, or so.
I just implemented this strategy and while it would work for packages that did not bring in too many dependencies, trying to build a more complex package in a clean chroot failed due to the large number of deps installed (e.g. xine-lib brings in 88 packages). The resulting package list is too long to be removed in one command (sudo: unable to execute /usr/bin/pacman: Argument list too long).
I don't see why this is necessary. If building using makepkg and you see it fails to remove deps, then get the list from "pacman -Qtd". If using makechrootpkg then just remove the "$CHROOT_SHELL/rw" directory and all is fixed. I see the failure to remove the installed packages as a failure in pacman. It should be able to "-Rs" chained dependencies and provides. I don't like working around the true source of the problem. So I doubt I will add to my initial patch - it solved the problem I was trying to solve and let the user know there was a problem removing deps which is all I think is necessary. If someone else wants to add to it then go for it.
Cheers, Allan
In fact we cannot restore the "before build state" in some cases. To satisfy a needed dependency makepkg may _upgraded_ a package (foo>=2.0 dependency) instead of add, then why should we remove foo? vmiklos's proposal is better here, because we may get some upgraded package after build which shouldn't hurt anything. However that solution can also fail, because your upgraded foo can pull _new_ dependencies which cannot be removed then. Bye ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/