> 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.
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.
SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu
This mail sent through IMP: http://horde.org/imp/
pacman-dev mailing list