[pacman-dev] What I'm working on- feedback welcome
I've got quite a few branches going on my GIT tree at the moment, and I'd appreciate any feedback from some of you on the list. They are all accessible here: http://code.toofishes.net/gitweb.cgi. * alpm.c_cleanup- move all of the alpm_pkg functions to package.c, alpm_db functions to db.c, etc. Basically put things where they logically belong leaving only the library initialization functions in alpm.c. This is ready to merge; I'm waiting because it could potentially break a lot for anyone else that has something that touched this file. * alpm_list_speed- this was just a test branch to see how much we were losing in efficiency by not having O(1) access to both ends of a list. Answer: a lot. pacman -Qo operations are a lot faster on this branch. However, this isn't meant for merge, it was more of a quick hack-job. * db_test- Add a pacman -Qt operation which tests the integrity of your database; ported over from the Frugalware pacman-g2. * frontend_config- move the pacman.conf parsing to the frontend where it belongs. Move a few pacman-only settings out of the library. In general, try to clean up where options and configs are stored. * gettext- gettext the remaining scripts in the scripts/ directory. I've had these patches sitting around for a while but never got them applied. Ready to be merged. * working- remove some hardcoded paths from the pacman binary, making everything configurable at runtime instead of compile time through pacman.conf. This means the only path now hardcoded into the pacman binary is that to pacman.conf, and no paths are compiled into libalpm. As I said, feedback on any of these is welcome and appreciated. -Dan
2007/6/4, Dan McGee <dpmcgee@gmail.com>:
I've got quite a few branches going on my GIT tree at the moment, and I'd appreciate any feedback from some of you on the list. They are all accessible here: http://code.toofishes.net/gitweb.cgi.
* alpm.c_cleanup- move all of the alpm_pkg functions to package.c, alpm_db functions to db.c, etc. Basically put things where they logically belong leaving only the library initialization functions in alpm.c. This is ready to merge; I'm waiting because it could potentially break a lot for anyone else that has something that touched this file.
* alpm_list_speed- this was just a test branch to see how much we were losing in efficiency by not having O(1) access to both ends of a list. Answer: a lot. pacman -Qo operations are a lot faster on this branch. However, this isn't meant for merge, it was more of a quick hack-job.
* db_test- Add a pacman -Qt operation which tests the integrity of your database; ported over from the Frugalware pacman-g2.
* frontend_config- move the pacman.conf parsing to the frontend where it belongs. Move a few pacman-only settings out of the library. In general, try to clean up where options and configs are stored.
* gettext- gettext the remaining scripts in the scripts/ directory. I've had these patches sitting around for a while but never got them applied. Ready to be merged.
* working- remove some hardcoded paths from the pacman binary, making everything configurable at runtime instead of compile time through pacman.conf. This means the only path now hardcoded into the pacman binary is that to pacman.conf, and no paths are compiled into libalpm.
As I said, feedback on any of these is welcome and appreciated.
Hm, that's already old, and wasn't able to look at any of these changes in details, but I suppose they are fine. afaik there is only the alpm_list_speed branch left now. But I've something to say about the config (and download) code that were in the backend : It seems like everyone agreed these belonged to the frontend (Aurelien first, then later, Aaron, Dan and Georg). Only vmiklos wanted these in the backend (not without arguments), see the first discussion there : http://www.archlinux.org/pipermail/pacman-dev/2006-January/005552.html Then later Aaron joined, and had to merge all frugalware change, which resulted in HUGE commits, including the move of config and download code to the backend. http://www.archlinux.org/pipermail/pacman-dev/2006-September/005884.html http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=d37ad04... http://projects.archlinux.org/git/gitweb.cgi?p=pacman.git;a=commit;h=3f27542... Note : I'm not blaming anyone here, and don't think anyone did anything bad, just thought this history was important to know :)
participants (2)
-
Dan McGee
-
Xavier