January 2007 - Pacman-dev - lists.archlinux.org

[pacman-dev] Install files and messages
by Dan McGee 09 Jan '07

09 Jan '07

I don't know what other peoples thoughts are, but I think the current install file system and scriptlets...seems like a drop in at some point that wasn't fully done right. Most packages currently use the file for one of two purposes that I can see: 1. display informational messages 2. perform operations that can't be done in the build phase. The install scriptlets were likely originally meant more for number 2, but has become more and more about providing number 1. Here are some relevant bugs and postings: metadata messages in PKGBUILD <http://bugs.archlinux.org/task/1571> display all post-install messages at once <http://bugs.archlinux.org/task/6143> global on-install system <http://bbs.archlinux.org/viewtopic.php?p=219152#219152> Here are my thoughts on the situation. As every package builder seems to have their own presentation format for displaying messages (e.g. echo ">>>...", echo " **...**"), it would be nice to have a way to unify it. Most (all?) messages are in one of two places- post_install or post_upgrade. I propose these messages should be moved out of these scriptlets, and moved into a variable, likely still located in the install file as this is packaged up with the package (unlike the PKGBUILD). These variables could be called install_msg and upgrade_msg, respectively. The scriptlets would still remain, but any output would be 'nonessential'. By changing where the messages stem from, it would make it easier for bug 6143 to be fixed, and would also make for cleaner output to pacman.log, now that all messages are being logged there. Finally, _alpm_runscriptlet seems pretty complicated...I'm wondering if it couldn't be cleaned up a bit by someone that is better with forks and popens. There is also some duplicate code. -Dan

4 5

[pacman-dev] makepkg fix (FS #5923)
by James Rosten 05 Jan '07

05 Jan '07

This is a fix for Flyspray bug #5923 http://bugs.archlinux.org/task/5923. Patch is below. ~ Jamie / yankees26

3 2

[pacman-dev] Long functions and other minor fixes
by James Rosten 02 Jan '07

02 Jan '07

This is my massacre of _alpm_load_pkg in package.c (just joking about the massacre). I moved the extremely large for loop into its own function (and made it a while loop). Feel free to change the name of _alpm_pkg_checker (first thing that came to mind). The patches for package.c and package.h are below. ~ Jamie / yankees26

3 4

[pacman-dev] My $0.02 on the Frugalware v.s. Arch bit...
by Scott Horowitz 01 Jan '07

01 Jan '07

I hate to wade into this, but let me just say... there's no doubt in my mind that this will never be resolved while the (inflammatory) sentiment in the pacman-g2 README exists. For starters, the whole point being made about the API not being stable, which seems to be points 1 and 2 in the README, are plain silly. No project should take a project's cvs development code and expect the API to remain stable; Frugalware knew what it was getting into when it grabbed this code to put into their repositories. There's a reason that pacman3 hasn't been released yet on Archlinux, and that there haven't been Archlinux frontends developed. Pacman3 development shouldn't be hindered because someone decided to release the code into the wild, and it's clearly going under some large refactoring. As for point 3, Aaron's supposed disinterest in contributor's patches - I think it has been quite clear from the mailing list that this isn't the case. The real justification behind this sentiment, which was brought up in the original email and I agree needs improvement, is that there could use more openness (such as in response to a WONTFIX patch) between all the parties. Then there's the stuff about how development has fallen behind schedule (what project hasn't?) and Aaron asked Frugalware to fork things (I'm pretty sure this was more tongue-in-cheeck about how Frugalware is doing things than anything). These seem pretty petty to me. In my opinion, two things need to happen, one from each side. On the Archlinux side, I think Aaron should make a better attempt to be more transparent in his responses, which would hopefully encourage debate. On the Frugalware side, I think the whining about API stability needs to be dropped and, rather than take the "fork" talk as a challenge, they should be asking what needs to be done to make the two paths more compatible. Happy Holidays, Scott

7 11