[Bryan, sorry for my previous direct reply.]
In terms of a warning, pacman already prints out lines like this:
warning: kernel26: ignoring package upgrade (2.6.27.8-1 => 2.6.27.10-1)
warning: pacman: ignoring package upgrade (3.2.1FIXBUG9395-1 => 3.2.1-2)
warning: pango: ignoring package upgrade (1.22.3-2 => 1.22.4-1)
Is that not sufficient?
No. If you check pacman/callback.c, you will see that
PM_TRANS_CONV_INSTALL_IGNOREPKG was used for asking the following
questions:
":: %s requires installing %s from IgnorePkg/IgnoreGroup. Install
anyway?" (by resolvedeps)
":: %s is in IgnorePkg/IgnoreGroup. Install anyway?" (Iirc, after
"pacman -S ignoredpkg").
These differ from sysupgrade (-Su) messages.
HOWEVER, in writing this very last line, I realize that my final test
should be:
if (is_needed(infolist, findinfo(infolist, deppkg), marker)) {
return(1);
}
This is because we want to consider a package needed if any of its
dependent packages are needed. The code as it was was mistakenly
considering a package needed only if all of its dependent packages are
needed.
Does that make sense?
Yes. And probably you want to change the final ("fall-back") return(1)
to return(0) in the function.
2. The result of this:
error: cannot resolve dependencies for:
error: foo
error: bar
...
This is ugly, we use data list for this purpose, the front-end should
build this message.
Please tell me exactly the format you want to see this error message
in, and I will make it so. I don't know exactly what you are expecting
so I am not sure how to fix the problem you are pointing out.
I guess we shouldn't print anything in alpm. Probably in the front-end
we will check pm_errno and print the correct error message using the
data list. I know that we had an error message here earlier, but I
don't like these redundant error messages. (Front-end always calls
_alpm_strerrorlast(), and processes data list).
+ if (data) {
+ alpm_list_t *targ = alpm_list_add(NULL,
i->data);
+ deps =
alpm_checkdeps(_alpm_db_get_pkgcache(local), 0, remove, targ);
This is not OK. (If this part existed in your previous patch, sorry for
missing it.) In the target list we may have a satisfier.
I don't understand what you are saying here. A few points:
1. The code already looked like this; I haven't changed how the
dependencies are checked in my patch. So what you are objecting to is,
I think, already the way that this code worked, not a change that I
have made.
2. I think you already talked about this in a previous email, when you said:
4. It is not easy to determine which package is unresolvable. If a
pulled dependency satisfier of foo is unresolvable we may could find an
other (resolvable) satisfier. But this is not handled in the current
code neither, so your _alpm_mark_unresolvable() is OK.
3. alpm_checkdeps just returns the list of dependencies for the
package. The very first thing that the code then does with each
dependency is look for it in the target list. Then if it's not found,
it uses _alpm_resolvedep to try to find a satisfier. Here is the code
in question:
No. pkg->depends or alpm_pkg_get_depends(pkg) is used to get the
dependency list of pkg. In the old code it was easy to determine if a
dependency is broken. If we couldn't find a satisfier package in the
target list or in the local database (which won't be upgraded), we
simply detected that this dependency is unresolvable. (However, our
error message was often uninformative, user may got an error message
like this: "Cannot resolve foo dependency of pulledpkg". User asked:
Pulledpkg? What? I just did "pacman -S bar". [1])
However, your patch makes things more complicated. We start to resolve
foo dependency of bar, which may be satisfied. But *later* it may turn
out, that we cannot resolve completely the _pulled_ foo satisfier, so
we simply remove it from the list. Now it would be elegant if we
could say: We could not resolve foo dependency of bar. (At this point
we can clearly see, that the old method doesn't work, because
*locally* foo is a resolvable dependency.) But it is not so easy to
detect, probably we need a more sophisticated info (graph?) structure,
and imho we can catch this broken dependency when we "label" the
package as unresolvable.
If we solve this problem, problem [1] will also disappear, which is an
extra benefit.
Bye
------------------------------------------------------
SZTE Egyetemi Konyvtar - http://www.bibl.u-szeged.hu
This message was sent using IMP: http://horde.org/imp/
_______________________________________________
pacman-dev mailing list
[email protected]
http://archlinux.org/mailman/listinfo/pacman-dev
