- Pacman-dev - lists.archlinux.org

[pacman-dev] [patch] remove configure check for bzip2
by Dan McGee 11 Jan '07

11 Jan '07

Switch to libarchive means this check should no longer be needed. Signed-off-by: Dan McGee <dpmcgee(a)gmail.com> --- --- pacman-lib.orig/configure.ac 2007-01-07 21:11:03.000000000 -0500 +++ pacman-lib/configure.ac 2007-01-08 10:55:01.000000000 -0500 @@ -291,14 +291,6 @@ JAVASTATUS="no, disabled by configure" fi -dnl Check for bzip2 -AC_CHECK_LIB([bz2], [BZ2_bzCompress], [AC_CHECK_HEADER([bzlib.h], [LIBBZ2='-lbz2'])]) -if test -n "$LIBBZ2"; then - LDFLAGS="$LDFLAGS $LIBBZ2" -else - AC_MSG_ERROR("bzip2 library and its include files are needed to build pacman!"); -fi - dnl Check for math AC_CHECK_LIB([m], [log10], [AC_CHECK_HEADER([math.h], [LIBM='-lm'])]) if test -n "$LIBM"; then

2 1

[pacman-dev] [patch] alpm documentation updates
by Dan McGee 11 Jan '07

11 Jan '07

There is still a lot more to do...someone on this list wants to step up to the plate and fix up the documentation. Signed-off-by: Dan McGee <dpmcgee(a)gmail.com> --- --- pacman-lib.orig/lib/libalpm/alpm.c 2007-01-03 03:05:13.000000000 -0500 +++ pacman-lib/lib/libalpm/alpm.c 2007-01-07 23:23:26.000000000 -0500 @@ -66,7 +66,7 @@ pmhandle_t *handle = NULL; enum __pmerrno_t pm_errno; /** \addtogroup alpm_interface Interface Functions - * @brief Function to initialize and release libalpm + * @brief Functions to initialize and release libalpm * @{ */ @@ -127,15 +127,11 @@ int alpm_release() return(0); } -/** @} */ -/** \addtogroup alpm_options Library Options - * @brief Functions to set and get libalpm options - * @{ - */ +/** @} */ /** \addtogroup alpm_databases Database Functions - * @brief Frunctions to query and manipulate the database of libalpm + * @brief Functions to query and manipulate the database of libalpm * @{ */ @@ -553,7 +549,7 @@ int alpm_pkg_vercmp(const char *ver1, co } /* internal */ -char *_supported_archs[] = { +static char *_supported_archs[] = { "i586", "i686", "ppc", @@ -589,7 +585,6 @@ char *alpm_pkg_name_hasarch(char *pkgnam return NULL; } - /** @} */ /** \addtogroup alpm_sync Sync Functions @@ -611,6 +606,7 @@ pmlist_t *alpm_db_search(pmdb_t *db) return(_alpm_db_search(db, handle->needles)); } + /** @} */ /** \addtogroup alpm_trans Transaction Functions @@ -764,24 +760,7 @@ int alpm_trans_release() return(0); } -/** @} */ -/** \addtogroup alpm_dep Dependency Functions - * @brief Functions to get informations about a libalpm dependency - * @{ - */ -/** @} */ - -/** \addtogroup alpm_conflict File Conflicts Functions - * @brief Functions to get informations about a libalpm file conflict - * @{ - */ - -/** Get informations about a file conflict. - * @param conflict database conflict structure - * @param parm name of the info to get - * @return a void* on success (the value), NULL on error - */ /** @} */ /** \addtogroup alpm_log Logging Functions @@ -894,6 +873,7 @@ int alpm_list_count(const pmlist_t *list return(_alpm_list_count(list)); } + /** @} */ /** \addtogroup alpm_misc Miscellaneous Functions @@ -1111,7 +1091,7 @@ int alpm_parse_config(char *file, alpm_c if(!strcmp(key, "SERVER")) { /* add to the list */ if(alpm_db_setserver(db, ptr) != 0) { - /* pm_errno is set by alpm_set_option */ + /* pm_errno is set by alpm_db_setserver */ return(-1); } } else { @@ -1127,6 +1107,6 @@ int alpm_parse_config(char *file, alpm_c return(0); } -/* @} */ +/** @} */ /* vim: set ts=2 sw=2 noet: */ --- pacman-lib.orig/doc/libalpm.3.in 2006-02-01 13:04:01.000000000 -0500 +++ pacman-lib/doc/libalpm.3.in 2007-01-07 23:23:23.000000000 -0500 @@ -1,4 +1,4 @@ -.TH libalpm 3 "29 Jan 2006" "libalpm @PM_VERSION@" "" +.TH libalpm 3 "07 Jan 2007" "libalpm @PM_VERSION@" "" .SH NAME libalpm \- Arch Linux Package Management library .SH SYNOPSIS @@ -6,13 +6,10 @@ For ease of access, the libalpm manual h .nf alpm_databases Database Functions -alpm_dep Dependency Functions -alpm_groups Group Functions alpm_interface Interface Functions alpm_list List Functions alpm_log Logging Functions alpm_misc Miscellaneous Functions -alpm_options Library Options alpm_packages Package Functions alpm_sync Sync Functions alpm_trans Transaction Functions

2 1

[pacman-dev] pacman-optimize updates
by James Rosten 11 Jan '07

11 Jan '07

Ok, after testing it, some changes needed to be made and so they were made. Now it works (at least for me it worked). This is just an idea, but wouldn't it be interesting if we used the stat_busy, stat_done, and stat_fail stuff from /etc/rc.d/functions for the messages in pacman-optimize? Anyway, here is the patch for FS #5009 (woops, just caught another bug.........it wouldn't be able to work after a successful one but it would work after the failure ('cause pacman.new was still haning around.........fixed). It is below as usual. ~ Jamie / yankees26

3 9

[pacman-dev] Pacman's new feature
by Fabiano Furtado Pessoa Coelho 10 Jan '07

10 Jan '07

Hi people, I´v been thinking about new feature on pacman. Why not to show the each package size on the install package list, just befere the download/instalation? Like: <package name> (SIZE) | <package name> (SIZE) | <package name> (SIZE) Thanks in advance... Fusca PS: Sorry about my english

2 1

[pacman-dev] pacman packaging
by Dan McGee 10 Jan '07

10 Jan '07

This was just another thought of mine. Pacman is currently distributed as one package on Archlinux (and I would assume on any distribution that is using it). I was thinking it should maybe be two packages, pacman and pacman-utils, or something similar. The two things can be split fairly cleanly- the first is used for installing packages and general maintenence, while the other is used for building packages, looking at the ABS tree, building a custom repo, etc. This also seems more important with a few other scripts being added recently (re-pacman, repo-add) pacman: pacman (and conf/man files), pacman.static, vercmp, rankmirrors, pacman-optimize pacman-utils: abs (and conf files), makepkg (and conf file), makeworld (TODO still wondering if this is used), gensync, resync, repo-add (TODO should this be renamed to addsync?), re-pacman In addition, pacman-utils could then pull in scripts such as srcpac and namcap that are likely installed by most developers anyway. This isn't so much development related, but I thought this was the best list to bring this up. -Dan

4 7

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

10 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 06 Jan '07

06 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 03 Jan '07

03 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 02 Jan '07

02 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

[pacman-dev] pacman-optimize updates
by James Rosten 31 Dec '06

31 Dec '06

I came up with a patch for FS #5009 (the error when /var/lib/pacman is a loopback device or other mounted partition. I have not been able to test it yet, as I am on my mac (so sending this with Mail, so let us hope it doesn't mess this up :P), but in a few hours I'll be on my Arch computer and I'll test it then and obviously report back. Also, fixed the step number in the comments ('cause I am that nit pickish), because there were two step 1's. ~ Jamie / yankees26

1 0