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

Bryan Ischo bji-keyword-pacman.3644cb at www.ischo.com
Wed Jan 14 07:04:10 EST 2009


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.
> 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!

Thanks,
Bryan



More information about the pacman-dev mailing list