[pacman-dev] New Patches

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

Allan McRae wrote:
> Bryan Ischo wrote:
>> Hey all.  I've broken my change into 5 patches, which have already 
>> been sent to the list.
>> The big one is patch #2, which adds the new ignore logic to deps.c.  
>> Although the number of lines edited is large, it's just the addition 
>> of a new data structure, some helper methods, and a rework of 
>> _alpm_resolvedeps().  There is no way to reduce the size of this patch.
>> I hope that these patches are satisfactory.  If you'd just give them 
>> a try they should merge nicely into your tree.  Create a branch and 
>> merge them in and test them out.  That's what git is good at right?!?
>> Please note that these patches replace all previous patches I've sent 
>> to this list.
>> Thanks,
>> Bryan
> Hi Bryan,
> The main patch (#2) is too complex for me to review, but on accepting 
> that as is, the other patches look quite reasonable.  I will give them 
> a proper spin when I do a testing build later.

Is there something I can do to make #2 clearer?  Is there someone who is 
going to review this and "bless" it for inclusion in the pacman 
sources?   Should I be addressing my emails to that person instead of 
the list?

> I just wanted to point out that you should not to get too discouraged 
> about the number of resubmits required for your patches.  Everybody 
> who submits patches here goes through the same thing, especially with 
> their first patch and yours are quite ambitious. You should see the 
> changes required any time I touch the pacman code...

Thank you for the encouraging words.  I did get a little frustrated 
earlier today and I'm sure that came through in my posts.  But I'm 
feeling much better now as I think that the split up patches are 
actually better than the single big mega-patch that I had previously 
submitted.  And all of this patch manipulation has taught me alot about 
git, which I had previously been interested in learning (coming from a 
subversion background), but never had the opportunity to use in 
practice.  In working on pacman I feel that I have almost become sort of 
comfortable with git, at least with the basic operations, so regardless 
of what happens with my pacman patches, I feel very happy with what I'm 
getting out of the process.


More information about the pacman-dev mailing list