[pacman-dev] [PATCH 1/5] Fixed some innacuracies in the pactest README

Allan McRae allan at archlinux.org
Wed Jan 14 07:12:19 EST 2009

Bryan Ischo wrote:
> Allan McRae wrote:
>> Bryan Ischo wrote:
>>> Signed-off-by: Bryan Ischo <bryan at ischo.com>
>>> ---
>>>  pactest/README |   14 +++++---------
>>>  1 files changed, 5 insertions(+), 9 deletions(-)
>> It is much easier for us to comment on these patches if they are sent 
>> inline.
> My apologies.  I am new to git and I don't know how these things are 
> typically done.  After some research, I found this command for 
> creating patches and sending them off via email:
> git format-patch --signoff --stdout --attach HEAD^^ | git imap-send
> This puts the patch emails as draft emails on my IMAP server, and I 
> send them from there.  I've just read the documentation for git 
> format-patch and I believe that you are saying that I should add the 
> "--inline" option when generating patch emails in this way ... right?  
> If so, I'll be happy to do that in future.

I use "git format-patch master" then "git send-email <patch>".  See 

>> A dictionary that holds the data used in the pacman configuration file.
>> -It has 3 keys, each one of them pointing at a list of strings:
>> -  - noupgrade
>> -  - noextract
>> -  - ignorepkg
>> Why remove this documentation rather than correcting it?  I suppose 
>> there are getting too many options to list in bullet point format but 
>> can they be listed in a sentence?
> There are too many options to list in bullet point, and when options 
> are added to/removed from pacman.conf, this list will be out of date.  
> I suspect that nobody is going to bother keeping this list up-to-date 
> (it certainly wasn't up-to-date when I was reading these docs!), so I 
> felt that rather than having an inaccurate list, it's better to have 
> no list at all.  I believe that the documentation examples make it 
> pretty clear that the dictionary keys are the pacman.conf options, and 
> I think that anyone developing pactest tests almost certainly would 
> already be familiar with what those options are, and how to find out 
> more about them (by reading documentation on pacman.conf) if they need 
> to.
> That was my reasoning anyway.  If you feel that it's better to have 
> the list, then I will be happy to add it back in.  But I can't promise 
> that I will maintain it as options are added to/removed from pacman!

Good point.  My main concern is "It has 3 keys, each one of them 
pointing at a list of strings:".  Maybe replace it with something like 
"it takes a key of the option being set and is assigned a list of strings"


More information about the pacman-dev mailing list