[pacman-dev] Pacman, some thoughts
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). 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. I've documented about 3 projects, more than 50.000 lines of code using doxygen the past week, and must say i'm happy with the result. Especially for the public SOAP interface it's nice having it, but also for internal reference and new developers who need some description about the functions in the code. And, hands (and heads) down, the code itself (functions etc.) isn't well inline documented. The last, but not least thing: SOURCE releases of RCs / nightly CVS checkouts. I've always been thinking about daily source tarballs. I've been thinking about providing such a script on my own, but my current provider forbids to have a public server running (sad but true, with cable 6mbit in/out). Why so? I'm often somewhere around the world, because of my job (italy, germany, ...), where i often connect in other infrastructures. I've to use a proxy, not supporting CVS. Since i havn't much to do in the evenings there, i actually want to do something - but can't. I don't think i'm the only one who would like nightly source checkouts being provided "as tarball".
On Wed, 28 Feb 2007 10:27:39 +0100
"Georg Grabler"
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).
Just a note that goto in and of itself isn't bad - it's all dependent on how it's used. That said, I haven't really looked at the pacman code itself, so don't know how it's used within there. -- Travis
On 2/28/07, Georg Grabler
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
participants (3)
-
Dan McGee
-
Georg Grabler
-
Travis Willard