[pacman-dev] [PATCH 3/3] Don't prompt the user for unignore of IgnorePkg/IgnoreGroup packages

[Bryan Ischo]

Dan McGee wrote:
> On Mon, Jan 26, 2009 at 6:48 AM, Bryan Ischo
> <bji-keyword-pacman.3644cb at www.ischo.com> 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