Dan McGee wrote:
On Mon, Jan 26, 2009 at 6:48 AM, Bryan Ischo
<[email protected]> wrote:
/* helper function for resolvedeps: search for dep satisfier in dbs */
-pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs, alpm_list_t
*excluding, pmpkg_t *tpkg)
+pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs, alpm_list_t
*excluding, int prompt_for_unignore)
It might be helpful if we threw some doxygen block commenting on this
guy, and then shortened the last argument to just "prompt", rather
than this rather long variable name. You can wrap the line too. :P
OK.
diff --git a/pactest/tests/ignore001.py b/pactest/tests/ignore001.py
new file mode 100644
index 0000000..bf8e8c6
--- /dev/null
+++ b/pactest/tests/ignore001.py
@@ -0,0 +1,17 @@
+self.description = "Sync with irrelevent ignored packages"
s/relevent/relevant/g in your descriptions. Spelling.
Well that seems pretty irrelevant, but I'll do as you ask :)
Although I do think that 'irrelevent' makes more sense: ir = not, rel =
related to, event = this event, i.e. not related to this event :)
+
+self.addrule("PACMAN_RETCODE=0")
+self.addrule("PKG_VERSION=packageA1|1.0-1")
+self.addrule("PKG_VERSION=packageA2|2.0-1")
+self.addrule("PKG_VERSION=packageA3|1.0-1")
+self.addrule("PKG_VERSION=packageA4|2.0-1")
+self.addrule("PKG_VERSION=packageA5|2.0-1")
Are there any pactests that could be written that have pacman
returning 1? Or does that just not happen anymore with this new
machinery (or at least isn't pactest-able)?
Yes, plenty of tests still return pacman error codes. The only ones
that don't are the ones that have unresolvable dependencies, and thus
have their default "cancel this operation" prompt option chosen. But
other kids of failures, will certainly continue to return an error code.
One thing that could be done is to make pactest able to answer prompts
as instructed by the individual test scripts (maybe there is already a
way to do this and I missed it?), and have some/all of these answer the
new prompt so as *not* to cancel the transaction, thus instituting the
same pacman behavor for all of these tests as before my changes
(returning error codes and whatever other side effects). However, I am
not a python programmer and I didn't feel like coming up to speed on
python just to enhance pactest in this way so I didn't do that ...
- /* TODO we take this route based on data2 being
not null? WTF */
Nice, you killed one of my longstanding comments!
Yes, I have to admit, it felt very satisfying ... nothing like
obsoleting a WTF?!?
Thanks,
Bryan
_______________________________________________
pacman-dev mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/pacman-dev