[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