[pacman-dev] Pacman, some thoughts

[Dan McGee]

On 2/28/07, Georg Grabler <ggrabler at gmail.com> wrote:
> Hello,
>
> I still spend some time looking a bit curious at pacman.
> It's rather the way it's coded, than the current features it provides.
>
> I mean, it's using quite everything marked as "bad style" in most
> books, and alot of those things could actually be avoided (Macros,
> goto).

Realize we inherited a lot of this code, and we may not like all these
things either. Some things are not all that bad if used correctly, as
Travis already replied, but other things we would like to get rid of.

Remember, we only have limited time to develop pacman- Aaron and I
have other things to do too, so we can't make this thing perfect
overnight. If you want to take the initiative to fix something,
perhaps mention it on the list and then submit a patch a few days
later.

Also keep in mind that for the next few weeks, we don't want to do
anything that can cause breakage- we are trying to get a release out
the door. After that, I think it may be a good idea for anyone with
interest to get their ideas for improvement in a melting pot, and
we'll go from there.

> The 2nd thing is: You've been talking (and mentioning) ALPM
> documentation. I personally dislike manpages for interface
> documentation. I rather think about a interface documentation using
> Doxygen or similar tools.

We've already started with doxygen- all of the libalpm manpages are
currently done WITH doxygen, not done on their own. We have been
working with the front end manpages, which are much more important for
getting a release out.

If you look at alpm.c, you'll see doxygen documentation there. It
could use a cleanup. In addition, I would really like to see the
entire backend documented this way, whether the functions are private
or public. I'm aware of the not-so-good documentation- it took me
quite a while to get the feel of pacman's flow and functions when I
started looking at it.

> The last, but not least thing: SOURCE releases of RCs / nightly CVS checkouts.
> I've always been thinking about daily source tarballs.

I guess I miss the point here, but this doesn't seem too necessary to
me for a few reasons. One, our code is really not changing that fast,
so why would a slightly outdated CVS checkout not serve the same
purpose? Two, any changes you make would be against outdated code
without the ability to easily do a cvs update, and thus any patches or
changes you would want to make would no longer be relevent. Three, I
just don't know if the interest is that high, but correct me if I'm
wrong.

-Dan