- Pacman-dev - lists.archlinux.org

[pacman-dev] PLEASE take my patches. PLEASE.
by Bryan Ischo 15 Feb '09

15 Feb '09

I hate to be reduced to begging, but after weeks of no one taking my patches, this is what I have to do. I jumped through every hoop I was asked to jump through to get my patches accepted (and to be honest, there were ALOT of hoops). My most recent patches apply to the source code without any conflicts and address all outstanding issues raised on this list. Dan McGee said that if I addressed those issues, he'd take my patches. Well I did, weeks ago, and yet, my patches are not in the tree. So this is one last attempt on my part to try to get a pacman dev to apply my patches to the master git tree. It should be trivially easy - should take all of a few seconds. Thanks, Bryan

3 3

[pacman-dev] HTML email will be rejected
by Aaron Griffin 13 Feb '09

13 Feb '09

Hello all, I am writing to inform you that I have changed all the Arch lists to reject HTML formatted email. Please send messages in plain text only. Note: This is true of all lists, but I am only sending this message to the higher trafficked lists. Cheers, Aaron

1 1

[pacman-dev] [PATCH] repo-add: added a realpath implementation in bash
by Yun Zheng Hu 11 Feb '09

11 Feb '09

When realpath or readlink is not available it will fallback to a realpath implementation in bash. An extra check is also added for "readlink -f", because not all platforms support the -f flag. The readlink implementation in bash is borrowed from Debian's dpkg tools. Signed-off-by: Yun Zheng Hu <yunzheng.hu(a)gmail.com> --- scripts/repo-add.sh.in | 23 ++++++++++++++++++++--- 1 files changed, 20 insertions(+), 3 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index c89e2a5..ea16731 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -297,11 +297,28 @@ fi # check for and store the name of a realpath-like program if [ $(type -t realpath) ]; then realpath='realpath' -elif [ $(type -t readlink) ]; then +elif [ $(type -t readlink) -a "$(readlink -f . 2>/dev/null)" != "" ]; then realpath='readlink -f' else - error "$(gettext "Either realpath or readlink are required by repo-add.")" - exit 1 # $E_MISSING_PROGRAM + realpath_bash() + { + fname=${1%/} # strips trailing '/' + while [ -L "$fname" ]; do + oldfname="$fname" + fname="$(command ls -l $fname)" + fname="${fname#*\> }" + if [ "$fname" = . ] ; then + fname="$(dirname $oldfname)" + elif echo $fname | grep -vq '^/' - ; then + fname="$(dirname $oldfname)/$fname" + fi + done + pushd $(dirname $fname) > /dev/null + fname=$(pwd -P)/$(basename $fname) + popd > /dev/null + echo $fname + } + realpath=realpath_bash fi # main routine -- 1.6.1.2

5 5

[pacman-dev] [PATCH] Allow vendor based DLAGENT settings in makepkg.conf
by Yun Zheng Hu 08 Feb '09

08 Feb '09

This patch will allow the default DLAGENT settings to be overridden in the configure script. This will allow better default DLAGENT settings for specific platforms/vendors. For example: Mac OS X does not have wget installed by default, but it does have curl by default. Currently the patch only overrides the default FTP and HTTP/HTTPS agents when configuring for Mac OS X. Signed-off-by: Yun Zheng Hu <yunzheng.hu(a)gmail.com> --- configure.ac | 20 ++++++++++++++++++++ etc/Makefile.am | 5 +++++ etc/makepkg.conf.in | 10 +++++----- 3 files changed, 30 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 2e7f433..0a63405 100644 --- a/configure.ac +++ b/configure.ac @@ -236,6 +236,26 @@ case "${host}" in ;; esac +# Configure DLAGENT settings, used in makepkg.conf +DLAGENT_FTP="ftp::/usr/bin/wget -c --passive-ftp -t 3 --waitretry=3 -O %o %u" +DLAGENT_HTTP="http::/usr/bin/wget -c -t 3 --waitretry=3 -O %o %u" +DLAGENT_HTTPS="https::/usr/bin/wget -c -t 3 --waitretry=3 --no-check-certificate -O %o %u" +DLAGENT_RSYNC="rsync::/usr/bin/rsync -z %u %o" +DLAGENT_SCP="scp::/usr/bin/scp -C %u %o" +case "${host_vendor}" in + apple) + DLAGENT_FTP="ftp::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 -o %o %u" + DLAGENT_HTTP="http::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 -o %o %u" + DLAGENT_HTTPS="https::/usr/bin/curl --location --continue-at - --retry 3 --retry-delay 3 --insecure -o %o %u" + ;; +esac + +AC_SUBST(DLAGENT_FTP) +AC_SUBST(DLAGENT_HTTP) +AC_SUBST(DLAGENT_HTTPS) +AC_SUBST(DLAGENT_RSYNC) +AC_SUBST(DLAGENT_SCP) + # Now do some things common to all architectures CHOST="${host}" AC_SUBST(CARCH) diff --git a/etc/Makefile.am b/etc/Makefile.am index 55c28c3..1605bfc 100644 --- a/etc/Makefile.am +++ b/etc/Makefile.am @@ -15,6 +15,11 @@ edit = sed \ -e 's|@SRCEXT[@]|$(SRCEXT)|g' \ -e 's|@CARCH[@]|$(CARCH)|g' \ -e 's|@CHOST[@]|$(CHOST)|g' \ + -e 's|@DLAGENT_FTP[@]|$(DLAGENT_FTP)|g' \ + -e 's|@DLAGENT_HTTP[@]|$(DLAGENT_HTTP)|g' \ + -e 's|@DLAGENT_HTTPS[@]|$(DLAGENT_HTTPS)|g' \ + -e 's|@DLAGENT_RSYNC[@]|$(DLAGENT_RSYNC)|g' \ + -e 's|@DLAGENT_SCP[@]|$(DLAGENT_SCP)|g' \ -e 's|@ARCHSWITCH[@]|$(ARCHSWITCH)|g' \ -e 's|@CARCHFLAGS[@]|$(CARCHFLAGS)|g' \ -e 's|@ROOTDIR[@]|$(ROOTDIR)|g' diff --git a/etc/makepkg.conf.in b/etc/makepkg.conf.in index d811867..d6c4ea6 100644 --- a/etc/makepkg.conf.in +++ b/etc/makepkg.conf.in @@ -8,11 +8,11 @@ # #-- The download utilities that makepkg should use to acquire sources # Format: 'protocol::agent' -DLAGENTS=('ftp::/usr/bin/wget -c --passive-ftp -t 3 --waitretry=3 -O %o %u' - 'http::/usr/bin/wget -c -t 3 --waitretry=3 -O %o %u' - 'https::/usr/bin/wget -c -t 3 --waitretry=3 --no-check-certificate -O %o %u' - 'rsync::/usr/bin/rsync -z %u %o' - 'scp::/usr/bin/scp -C %u %o') +DLAGENTS=('@DLAGENT_FTP@' + '@DLAGENT_HTTP@' + '@DLAGENT_HTTPS@' + '@DLAGENT_RSYNC@' + '@DLAGENT_SCP@') # Other common tools: # /usr/bin/snarf -- 1.6.1.2

3 2

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.2-5-gea84819
by dan＠archlinux.org 08 Feb '09

08 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via ea84819bbbdba90f950339790d482f2348c2e9ef (commit) from 472e51b975b9cb8fe1f67c03ff72bbc067fa7f01 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.2-78-g04c2b9d
by dan＠archlinux.org 08 Feb '09

08 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via 04c2b9d4edb7f7e592919fa3bb975f9edd4fa0a6 (commit) via ea84819bbbdba90f950339790d482f2348c2e9ef (commit) via 34e1413d756269dcd71a32dd5d2dbb263a943051 (commit) via 14230869e6a37526f8a1bdb1fb88f23309b10aef (commit) via eab96848376db6f54f05773a7e924faf0355137f (commit) from c794661f1ea8c819d479948e92e5648de62787c5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 04c2b9d4edb7f7e592919fa3bb975f9edd4fa0a6 Merge: 34e1413d756269dcd71a32dd5d2dbb263a943051 ea84819bbbdba90f950339790d482f2348c2e9ef Author: Dan McGee <dan(a)archlinux.org> Date: Sun Feb 8 11:43:08 2009 -0600 Merge branch 'maint' commit 34e1413d756269dcd71a32dd5d2dbb263a943051 Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Mon Jan 19 22:54:00 2009 +0100 Delay the creation of local and sync db dir. We don't need to create the directories when local or sync dbs are registered. For example, if a sync db does not exist, we cannot even do "pacman -Q" as an user. Instead, we can create the local db if needed during the db_prepare operation, and sync dbs on db_update. Also remove some more useless abstractions in db_update and switch to a much more efficient way to remove a sync db : rm -rf. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> commit 14230869e6a37526f8a1bdb1fb88f23309b10aef Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Mon Jan 19 20:45:12 2009 +0100 Remove some db abstraction crap. These db_open and db_close looked quite useless. And they caused the db directory to be opened on a simple registering of a database. This is totally unneeded, this opening can be delayed to when we actually need it. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> commit eab96848376db6f54f05773a7e924faf0355137f Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Sun Jan 18 14:01:24 2009 +0100 alpm_unpack : change prefix handling to workaround FS#12148. Instead of appending the prefix to each entry name, we can chdir to the prefix before extracting, and restoring when it is done. This seems to work better with the strange and special case of FS#12148 where an archive contained the "./" entry. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/be_files.c | 81 ++++++++++++++++++++++------------------------- lib/libalpm/db.c | 41 ------------------------ lib/libalpm/db.h | 3 -- lib/libalpm/util.c | 32 ++++++++++++++----- scripts/makepkg.sh.in | 4 +- 5 files changed, 64 insertions(+), 97 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Any progress on my patches?
by Bryan Ischo 08 Feb '09

08 Feb '09

Hi all. It's been almost two weeks since I submitted my most recent patches, after much discussion, much back-and-forth, many changes, and many hours of work on my part. But I've heard nothing about the acceptance of my patches except "someone is reviewing them". To be quite blunt, I don't think my patches are being actively reviewed. If they were, I'd expect someone to have some questions for me about the code, something to indicate why the patches have not yet been applied. But I'm not hearing anything so I conclude that in reality my patches simply aren't getting any attention. I think that what I really need to do is just remind the pacman source maintainers that my patches are out there and I'm waiting for them to be accepted. I realize that everyone is busy with lots of stuff, and that the particular issue that my patches address may not be high on anyone's list of pacman priorities (although there is a bug open about it in flyspray, so it's at least important enough that it's being tracked as an issue). But I think I've been very patient - it's been weeks since I submitted my patches - and I really hope that someone can just accept my patches so that I can put this issue to rest. I'm really worried that as time goes on and other changes go into the pacman sources, my patches have a greater and greater chance of needing to be re-worked to be accepted. And I've already spent a great deal more time than I anticipated on this, I really don't want to spend any more if I don't have to. So somebody, *please*, accept my patches, or let me know what I need to do to get them accepted. By the way, please note that my most recent version of these patches, of almost two weeks ago, address the issues that Dan McGee had raised that I hadn't responded to. There are no outstanding issues that these patches have not addressed. Thanks, Bryan ------------------------------------------------------------------------ Bryan Ischo bryan(a)ischo.com 2001 Mazda 626 GLX Hamilton, New Zealand http://www.ischo.com RedHat Fedora Core 5 ------------------------------------------------------------------------

1 0

[pacman-dev] [PATCH] makepkg: Make stripping debug symbols cross-platform
by Sebastian Nowicki 08 Feb '09

08 Feb '09

The Linux and BSD versions of strip have the --strip-debug option (as well as the -S option), however Mac OS X only has -S. --- scripts/makepkg.sh.in | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 1b2f042..e10c345 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -834,9 +834,9 @@ tidy_install() { find ${STRIP_DIRS[@]} -type f 2>/dev/null | while read binary ; do case "$(file -biz "$binary")" in *application/x-sharedlib*) # Libraries (.so) - /usr/bin/strip --strip-debug "$binary";; + /usr/bin/strip -S "$binary";; *application/x-archive*) # Libraries (.a) - /usr/bin/strip --strip-debug "$binary";; + /usr/bin/strip -S "$binary";; *application/x-executable*) # Binaries /usr/bin/strip "$binary";; esac -- 1.6.0.1

2 1

Re: [pacman-dev] Hooks for pacman, more ideas
by Mårten Olsson 03 Feb '09

03 Feb '09

----- "Mårten Olsson" <marten.olsson(a)purplescout.se> wrote: > ----- "Allan McRae" <allan(a)archlinux.org> skrev: <snip> > > >> I'm sure it would be possible to have a package set off a hook > such > > as > > >> you are suggesting, although I think most packages would have a > > file > > >> that would be the obvious choice to use (e.g. /boot/vmlinuz26 for > > >> kernel26). Please add a comment to the wiki page about this. > > >> > > >> > > > Yep, I don't see that as a major problem. > > > From what I have seen of the code it might however be easier to > > start > > > with Package matching (I might be wrong about this but it is my > > personal > > > opinion). In the end both options would be good, we have > > > at least seen that between us that both variants are desirable. > > > > > > > > > > From my understanding, there should be a list of files involved in > a > > transaction created during conflict checking. So we can hopefully > use > > that to test which hooks need to be run. However, I am not very > > familiar with that part of the pacman code... > > > > Ah that seems resonable. > I have done some looking around and the as far as I understand it it would be possible to use "alpm_pkg_get_files" whenever a package is installed/ upgraded/removed to find files to match. Do you know if that is possible? Also it seems like good places to check the hooks would be around the same places where it is currently checked if a package has a scriptlet (where "alpm_pkg_has_scriptlet" is called in the "commit_single_pkg" and "_alpm_remove_commit" functions). The hooks should probably be run after the package scriptlets, rigth? Your ideas? I also have tried to find good places for the "Transaction" hooks but have really found a really good place, maybe in "_alpm_trans_free" but I don't understand enought about the transation part of the code to determine if that is a good place... I also have one question about the config syntax: Currently the syntax is something like: [<script to run>] Files = <file to match> (or Package = <packagename> if that idea is added) Run = <time to run the script> [<script to run2>] Files = <file to match2> (or Package = <packagename2> if that idea is added) Run = <time to run the script> What about lay it out like this instead: [time to run the script] File = <file to match> (or package) Run = <script> File = <file to match2> (or package2) Run = <script2> [time to run the script2] File = <file to match3> (or package) Run = <script3> My personal opinion is that it gives a cleaner seperation as the "section header" determines at which point "in time" to run the hook and it would be more static thing to search/compare with when parsing the config. What do you think? > > Allan > > //Mårten

3 2

Re: [pacman-dev] [PATCH] Add support for user defined per package post install actions
by Mårten Olsson 01 Feb '09

01 Feb '09

Hi! Oh, that was a neat idea... Which I have unfortunetly missed when searching in the archives. :-) I think it should be possible to have it triggered by packages as well, something like this: [kernel-install] Package = kernel26 Run = rebuildoutofkerneltreedrivers (I recognice the ridiculous name of the Run-argument and that this probably wouldn't work as a reboot probably is necessery first but just something as an example. (and it was this need that triggered my own idea).) Of course it is possible to have it triggered by file in this case as well, just list files in this package and choose one of them, but it is still an unecessery extra step (even if it is a small one). BR, Mårten ----- Original Message ----- From: "Allan McRae" <allan(a)archlinux.org> To: "Discussion list for pacman development" <pacman-dev(a)archlinux.org> Sent: Sunday, February 1, 2009 2:59:10 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [pacman-dev] [PATCH] Add support for user defined per package post install actions Hi, This seems similar to the hooks mechanism the we have been discussing but less general. Have a look at http://wiki.archlinux.org/index.php/User:Allan/Pacman_Hooks for more information. So in short, I like the idea but would want a more general approach taken. Allan Mårten Olsson wrote: > Hi all! > > Wasn't sure if I could include additonal text in "patch-mail". > So I hope it is ok to send an additonal mail with extra info: > > At some places the code needs cleanup which I will do if the concept shown > is accepted (didn't want to take to much time on that if the concept is disliked > and never will be accpeted for that reason). > I want to fix the code-duplication issue (one function) and make the parsign so one > can have arguments with spaces inside " ". > > I wasn't sure if this functionality can be considered dangerous because it will run a script > with full access to the system, but I guess the same problem could show up if you make "bad" > packages with an install script. > > BR, > Mårten > > ----- Original Message ----- > From: "Mårten Olsson" <marten.olsson(a)purplescout.se> > To: pacman-dev(a)archlinux.org > Sent: Sunday, February 1, 2009 2:36:46 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna > Subject: [pacman-dev] [PATCH] Add support for user defined per package post install actions > > This adds suport for user to add per package post install > actions, somewhat similar to post-install scripts in packages > but controlled by local user and not part of package/not done > by package maintainer. > The actions is performed by "system" call and can't contain > spaces (not even when inside "). > Syntax in logfile is > PostInstallAction = <packagename>:<action> > Functionality added inside libalpm, add support for configuring > in pacman. > > Signed-off-by: Mårten Olsson <marten.olsson_at_purplescout.se> > --- > lib/libalpm/add.c | 43 +++++++++++++++++++++++++++++++++ > lib/libalpm/alpm.h | 3 ++ > lib/libalpm/handle.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++ > lib/libalpm/handle.h | 6 ++++ > src/pacman/pacman.c | 20 +++++++++++++++ > 5 files changed, 137 insertions(+), 0 deletions(-) > > diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c > index 6eb2085..1cd6e28 100644 > --- a/lib/libalpm/add.c > +++ b/lib/libalpm/add.c > @@ -632,6 +632,46 @@ static int extract_single_file(struct archive *archive, > return(errors); > } > > +static int postinstallcompare(const void *postinstalldata, const void *pkgname) > +{ > + const postinstallaction_t *postinstallaction=postinstalldata; > + > + if( (pkgname != NULL) && (postinstallaction->pkgname != NULL) && (strcmp(postinstallaction->pkgname, pkgname) == 0)) { > + return(0); > + } > + > + return(1); > +} > + > +/** Test if a package has a postinstallaction associated with it and executes the action. > + * > + * Checks if the package has a postinstallaction associated with it > + * and if so executes the action by the system call > + * > + * @param pkg the package to test > + * > + * @return 0 if no action found or if the associated action completed succesfully, 1 otherwise > + */ > +static int check_run_postinstallaction(pmpkg_t *pkg) > +{ > + postinstallaction_t *postinstallaction = NULL; > + > + _alpm_log(PM_LOG_DEBUG, "PostInstallAction: finding PostInstallAction for package: %s\n", alpm_pkg_get_name(pkg)); > + > + postinstallaction=alpm_list_find(handle->postinstallactions, alpm_pkg_get_name(pkg), postinstallcompare); > + > + if( postinstallaction != NULL) { > + _alpm_log(PM_LOG_DEBUG, "PostInstallAction: package: %s action: %s \n", postinstallaction->pkgname, postinstallaction->action); > + > + /* should this be more like the install-scriptlet code */ > + if( system(postinstallaction->action) != 0) { > + return(1); > + } > + } > + > + return(0); > +} > + > static int commit_single_pkg(pmpkg_t *newpkg, int pkg_current, int pkg_count, > pmtrans_t *trans, pmdb_t *db) > { > @@ -847,6 +887,9 @@ static int commit_single_pkg(pmpkg_t *newpkg, int pkg_current, int pkg_count, > } > } > > + /* check and run postinstall action */ > + check_run_postinstallaction(newpkg); > + > if(is_upgrade) { > EVENT(trans, PM_TRANS_EVT_UPGRADE_DONE, newpkg, oldpkg); > } else { > diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h > index 7b7ca4e..04ff886 100644 > --- a/lib/libalpm/alpm.h > +++ b/lib/libalpm/alpm.h > @@ -122,6 +122,9 @@ void alpm_option_add_noupgrade(const char *pkg); > void alpm_option_set_noupgrades(alpm_list_t *noupgrade); > int alpm_option_remove_noupgrade(const char *pkg); > > +int alpm_option_add_postinstallaction(const char *pkg, const char *action); > +int alpm_option_remove_postinstallaction(const char *pkg); > + > alpm_list_t *alpm_option_get_noextracts(); > void alpm_option_add_noextract(const char *pkg); > void alpm_option_set_noextracts(alpm_list_t *noextract); > diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c > index 813f439..504157d 100644 > --- a/lib/libalpm/handle.c > +++ b/lib/libalpm/handle.c > @@ -53,6 +53,23 @@ pmhandle_t *_alpm_handle_new() > return(handle); > } > > +void postinstallactionfree(void *data) > +{ > + postinstallaction_t *postinstallaction=data; > + > + if(postinstallaction->pkgname != NULL) > + { > + free(postinstallaction->pkgname); > + } > + > + if(postinstallaction->action != NULL) > + { > + free(postinstallaction->action); > + } > + > + free(postinstallaction); > +} > + > void _alpm_handle_free(pmhandle_t *handle) > { > ALPM_LOG_FUNC; > @@ -84,6 +101,8 @@ void _alpm_handle_free(pmhandle_t *handle) > FREELIST(handle->noextract); > FREELIST(handle->ignorepkg); > FREELIST(handle->ignoregrp); > + alpm_list_free_inner(handle->postinstallactions, postinstallactionfree); > + alpm_list_free(handle->postinstallactions); > FREE(handle); > } > > @@ -453,6 +472,52 @@ int SYMEXPORT alpm_option_remove_noupgrade(const char *pkg) > return(0); > } > > +int SYMEXPORT alpm_option_add_postinstallaction(const char *pkg, const char *action) > +{ > + postinstallaction_t *postinstallaction=0; > + > + postinstallaction=malloc(sizeof(postinstallaction_t)); > + > + if(postinstallaction == NULL) { > + return(1); > + } > + > + postinstallaction->pkgname = strdup(pkg); > + postinstallaction->action= strdup(action); > + > + handle->postinstallactions = alpm_list_add(handle->postinstallactions, postinstallaction); > + > + return(0); > +} > + > +/* Duplicated here for now, cleanup needed */ > +static int postinstallcompare(const void *postinstalldata, const void *pkgname) > +{ > + const postinstallaction_t *postinstallaction=postinstalldata; > + > + if( (pkgname != NULL) && (postinstallaction->pkgname != NULL) && (strcmp(postinstallaction->pkgname, pkgname) == 0)) { > + return(0); > + } > + > + return(1); > +} > + > +int SYMEXPORT alpm_option_remove_postinstallaction(const char *pkg) > +{ > + postinstallaction_t *postinstallaction=0; > + > + handle->postinstallactions=alpm_list_remove(handle->postinstallactions, pkg, postinstallcompare, (void *)&postinstallaction ); > + > + if( postinstallaction != NULL) { > + free(postinstallaction->pkgname); > + free(postinstallaction->action); > + free(postinstallaction); > + return(1); > + } > + > + return(0); > +} > + > void SYMEXPORT alpm_option_add_noextract(const char *pkg) > { > handle->noextract = alpm_list_add(handle->noextract, strdup(pkg)); > diff --git a/lib/libalpm/handle.h b/lib/libalpm/handle.h > index ad7666d..c53e7f6 100644 > --- a/lib/libalpm/handle.h > +++ b/lib/libalpm/handle.h > @@ -28,6 +28,11 @@ > #include "alpm.h" > #include "trans.h" > > +typedef struct _postinstallaction_t { > + char *pkgname; > + char *action; > +} postinstallaction_t; > + > typedef struct _pmhandle_t { > /* internal usage */ > pmdb_t *db_local; /* local db pointer */ > @@ -53,6 +58,7 @@ typedef struct _pmhandle_t { > alpm_list_t *noextract; /* List of files NOT to extract */ > alpm_list_t *ignorepkg; /* List of packages to ignore */ > alpm_list_t *ignoregrp; /* List of groups to ignore */ > + alpm_list_t *postinstallactions; /* List of packages to perform actions postinstall */ > > /* options */ > unsigned short usesyslog; /* Use syslog instead of logfile? */ /* TODO move to frontend */ > diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c > index 59916d6..1f1371d 100644 > --- a/src/pacman/pacman.c > +++ b/src/pacman/pacman.c > @@ -549,6 +549,24 @@ static void option_add_syncfirst(const char *name) { > config->syncfirst = alpm_list_add(config->syncfirst, strdup(name)); > } > > +/* helper for being used with setrepeatingoption, additional parsing done here*/ > +static void option_add_postinstallaction(const char *string) { > + char *name = (char *)string; > + char *action = 0; > + > + action=strchr(string,':'); > + > + if( action != NULL) { > + *action = '\0'; > + action++; > + > + pm_printf(PM_LOG_DEBUG, "config: Postinstallaction package %s action: %s\n", name, action); > + > + alpm_option_add_postinstallaction(name, action); > + } > + > +} > + > /** Add repeating options such as NoExtract, NoUpgrade, etc to libalpm > * settings. Refactored out of the parseconfig code since all of them did > * the exact same thing and duplicated code. > @@ -710,6 +728,8 @@ static int _parseconfig(const char *file, const char *givensection, > setrepeatingoption(ptr, "HoldPkg", option_add_holdpkg); > } else if(strcmp(key, "SyncFirst") == 0) { > setrepeatingoption(ptr, "SyncFirst", option_add_syncfirst); > + } else if(strcmp(key, "PostInstallAction") == 0) { > + setrepeatingoption(ptr, "PostInstallAction", option_add_postinstallaction); > } else if(strcmp(key, "DBPath") == 0) { > /* don't overwrite a path specified on the command line */ > if(!config->dbpath) { > _______________________________________________ pacman-dev mailing list pacman-dev(a)archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

2 4