> Here I send you the gzipped unified cvs diff. > This is intended to be applied to the current CVS > (I've done a diff between the current apt-get.cc and my patched one).
ok, so other than stylistic issues, I think your patch is actually quite similar to what I've commited, some comments: - The handling of build-conflicts seems counterintuitive. I haven't seen an example of a build-conflicts that has a | in it, but I would suspect "Build-Conflicts: a | b" means we conflict against both a and b. (policy is not clear on this issue...) In your code you would remove 'a' only. - you have some extraneous variables in your code. e.g. 'startor' is not used. - I don't understand how this would work: you only allow one package to be pushed into the toinstall list in your "or" handling loop, how can toinstall.size() be > 1 in the subsequent code? (ditto for toremove) Actually I think it's good to show the user if there are multiple OR alternatives that can satisfy a build-dep and do some more intelligent handling. Here's one case that is not handled very well: legolas[10:01] ~% apt-cache showsrc alsaplayer|grep Build-Dep Build-Depends: [...] xlibmesa-dev | libgl-dev, [...] Suppose I have libgl-dev installed, the build-dep code would still try to install xlibmesa-dev, and fail even if xlibmesa-dev is not installable (like it is in unstable at the moment). Fixing this is non-trivial tho (at least to me...). We can probably detect libgl-dev is installed and not do anything, but it's harder to determine that xlibmesa-dev is not installable and we should try libgl-dev instead, etc. In any case, | in build-deps are evil in general, so it may be good enough to print out some better error messages and fail. randolph -- Randolph Chung Debian GNU/Linux Developer, hppa/ia64 ports http://www.tausq.org/
