[pacman-dev] -Sp is broken?

[Xavier]

On Thu, Oct 04, 2007 at 01:18:11PM +0200, Nagy Gabor wrote:
> 
> Well, I'm pretty sure that we should restructure pacman's option "handling".
> Sometimes "rethinking" a big codepart is easier than fixing ~100 flyspray bugs
> (as an example, I must mention the current libalpm/sync.c ...)
> See also (this method is the most pausible for me; the effects of this would
> restructure the source, too):
> http://www.archlinux.org/pipermail/pacman-dev/2007-September/009484.html
> 

Unfortunately, no one is going to do it.
I'm not sure I could do it (I suck, I have no experience in C, no experience
in pacman, and understanding some part of the pacman code takes me ages).
And in any cases, I'm afraid I don't have the motivation.
I find the amount of TODO things really depressing :)

And Aaron and Dan already have already plenty of things to do in pacman. For
example, preparing for 3.1 release, handling all the bug reports (I don't
think most of them are related to libalpm/sync,c code), and also plenty of
others non-pacman arch-related things.

> I don't really understand where the difficulty is. We can loop in the operation
> options, and do the requested operations.
> Permission handling: Do we really need this?
> libalpm will return with an error, if the user hasn't got enough privileges; and
> pacman can quit (any may ignore -y). libalpm could also inform the caller
> funtion about "Operation not permitted" with an error-type.
> 

That's probably a good idea, but is it really that easy?
What happens if you have enough privileges to do some stuff, but not enough
for completing the transaction, and pacman fails in the middle of it?

But apparently, ideas are not welcome here anyway. Since Aaron is familiar
with the code base, he already knows about many of them, so this doesn't help
him. Patches would help more.
And Dan apparently finds that your descriptions / explanations of problems
are hard to understand, and your patches hard to read.. So that most likely
explains why some of them take so long to be merged..

In my opinion, git helps again here. It allows you to look back at your
patch, and try improving their readability. And also, you have the time to
work on the description of the commit, which explains the patch, and make it
as clear as possible.

However, I find that your ideas and patches are always right on spot, that
you fixed many bugs, and improved some parts of the code. So I think you are
a valuable contributor.
I hope you could try to listen to Aaron and Dan advices. That is, don't
submit so many ideas unless you are ready to work on them :)
And when you do provide a patch, try to make it as clear as possible. Just
place all chances on your side, so that your patch can be merged.