March 2008 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] Fix FS#8905 (-Sp as non-root)
by Nagy Gabor 10 Mar '08

10 Mar '08

From 80e66dda0239c04e75cda0771bd4627921aa098e Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sat, 8 Mar 2008 18:35:44 +0100 Subject: [PATCH] Fix FS#8905 (-Sp as non-root) This patch is quite ugly, but solves the issue without API change. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/trans.c | 14 +++++++++++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/lib/libalpm/trans.c b/lib/libalpm/trans.c index 52dbe7a..79a33f0 100644 --- a/lib/libalpm/trans.c +++ b/lib/libalpm/trans.c @@ -72,9 +72,11 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, ASSERT(handle->trans == NULL, RET_ERR(PM_ERR_TRANS_NOT_NULL, -1)); /* lock db */ - handle->lckfd = _alpm_lckmk(); - if(handle->lckfd == -1) { - RET_ERR(PM_ERR_HANDLE_LOCK, -1); + if(!(type == PM_TRANS_TYPE_SYNC && flags & PM_TRANS_FLAG_PRINTURIS)) { + handle->lckfd = _alpm_lckmk(); + if(handle->lckfd == -1) { + RET_ERR(PM_ERR_HANDLE_LOCK, -1); + } } handle->trans = _alpm_trans_new(); @@ -190,6 +192,7 @@ int SYMEXPORT alpm_trans_interrupt() int SYMEXPORT alpm_trans_release() { pmtrans_t *trans; + int nolock; ALPM_LOG_FUNC; @@ -197,6 +200,8 @@ int SYMEXPORT alpm_trans_release() ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1)); trans = handle->trans; + nolock = (trans->type == PM_TRANS_TYPE_SYNC) && (trans->flags & PM_TRANS_FLAG_PRINTURIS); + ASSERT(trans != NULL, RET_ERR(PM_ERR_TRANS_NULL, -1)); ASSERT(trans->state != STATE_IDLE, RET_ERR(PM_ERR_TRANS_NULL, -1)); @@ -204,6 +209,9 @@ int SYMEXPORT alpm_trans_release() handle->trans = NULL; /* unlock db */ + if(nolock) { + return(0); + } if(handle->lckfd != -1) { close(handle->lckfd); handle->lckfd = -1; -- 1.5.3.8

2 6

[pacman-dev] Re: Binary Database
by Dario Freddi 10 Mar '08

10 Mar '08

Hi Xavier, Sorry if I didn't hit you back immediately, but I wanted to read every discussion and make up my mind about the various proposals. So, let's go: I think we are more interested in trying to improve the current text based > one rather than switching to a binary database, at least as a first step. > For example, for the sync db, we could directly read from the archive : > http://bugs.archlinux.org/task/8586 > > Glad to hear. About the first one, I'm not a tar guru, and I don't know about how fast things could be if we read things from archive to memory. I've seen there is already some code for it, but benchmarks in real use cases would be better. What I fear is that reading too many times from a tar'ed archive could be somehow counterproductive (again, I could be completely wrong on that). I think that could be possible, if it's really worth it, but I don't have enough knowledge on this argument to say if that would be useful. I'd be glad to hear other voices. A second point of interest is unifying the format of the meta-info files inside the package (.PKGINFO) and the ones inside the database (depends / desc). Having just one format would simplify the code. We could also reduce the number of files in the sync and local database by merging them, which would reduce the impact of fragmentation and slow filesystems. http://www.archlinux.org/pipermail/pacman-dev/2007-June/008601.html This would surely be a plus, by now there is a real mess in the packages dirs, and it's useless, code-consuming and confusing to have different formats. Also, I propose to keep scriptlets in the Database. I clear my cache a lot of times for the sake of disk space, and whenever I try to remove a package, the remove scriptlet is not found. That could be harmful. It wouldn't be a lot of space. Just a random thought anyway. Otherwise, if we want to experiment with different backends, it would > probably be a good idea to try abstracting the backend code, so that we would > have all specific backend code in the same place, and have the possibility to > easily switch between several ones. That was also discussed ages ago, in the > same link as above : > http://www.archlinux.org/pipermail/pacman-dev/2006-March/005702.html > > This is *the* point. Everything we're saying is useless if we don't abstract things first. If we keep a "dirty" implementation, where backend code is mixed with database files parsing, porting improvements is a royal pain in that place. If we could create a set of functions that take care of giving out strings or files to parse to the current db functions in alpm, then changing the current backend, using multiple backend, have a CHOICE in backend choosing (imagine that! the end of the mother of all discussion in Arch Linux), it would be surely easier. Why don't we simply start from this? Let's make alpm a real library, let's abstract code, and let's create a dbbackend set of functions. If we study the code closely, and we want to do this (a bit boring) part, I can only imagine how many benefits we could take from this. I have nothing against the text-based database, but if we can "split" the backend part, it could have a lot of great benefits too. What do you think about that? More recently, there was an attempt of a sqlite backend : > http://www.archlinux.org/pipermail/pacman-dev/2008-January/011011.html > As you can see, this raises several problems of migrating the current code > base. And then there is also the problem of migrating the databases. > > Yeah, and that demostrates what I said in the last paragraph. Anyway, even if a bit OT, I think there could be a better solution than SQLite. Amarok with large (3000+) collection anyone? It takes ages to create collections, switching to MySQL makes things a lot faster. I'm not a SQLite guru again, but I have heard many voices saying that it's not so fast as it seems, especially in case it has a lot of entries (and that would be pacman's case). I'd like to hear someone competent (clarification : Competent doesn't mean "OMG text based sucks go SQLite because I was told it is faster" trolls, I mean arguments, benchmarks, and maybe a pair of lines of code that show how SQLite can handle a large DB). Well, I hope that throwing out some random ideas about the backend that were > discussed here wasn't too confusing. > But I think there is definitively an interest for improving the backend in > > No, that wasn't confusing at all :) I'm glad to hear that pacman developers know the current situation and want to do something about it. Well, voices don't always tell the truth, I expected a completely different answer here. I would be glad if we could come out with a plan and make things better, from us (me and other 2-3 people), there is a real interest in making alpm even better. Sorry for the long mail Cheers, Dario one way or another. > >

4 3

[pacman-dev] [Translation] [Chinese Simplified] update
by gan lu 10 Mar '08

10 Mar '08

A few improvement, thanks.

1 0

[pacman-dev] [patch] makepkg: add checksums and resume
by Ray Rashif 10 Mar '08

10 Mar '08

Hi Sorry for the interruption. As someone who makes use of this tool regularly, being able to include the hash-checks in one shot is helpful. Having an alias is alright but in some situations, not enough. I've now decided to simply include it in makepkg. For the benefit of $anybody here it is attached. If you don't know how to apply a patch and you're reading this (gasp!), do the following as root: patch -Np0 /usr/bin/makepkg /path/to/this/makepkg-checkresume.patch Summary: + variable GETINTEG + function insert_checksums + option -G,--getinteg eg. To rule the world at once with style we run "makepkg -Gic" It isn't that much warranted. However, it _can_ save some time. Something like this and Roman's download-resume patch would be good additions for the next update. If this has already been implemented in some other way, I'll be glad to see it soon. Now for a Q&A session. It appears that makepkg will be in $srcdir when it's called. However, I noticed the following under devel_update function: sed -i "s/^pkgver=[^ ]*/pkgver=$newpkgver/" ./$BUILDSCRIPT source $BUILDSCRIPT I didn't test this as I have no svn et al packages currently, but I see "source $BUILDSCRIPT" a lot. Just wondering whether we need to type in $startdir for every action on $BUILDSCRIPT. Anyway, I think some parts can directly make use of variables from makepkg.conf - messages for instance. I've reflected this to a little extent in this patch, like DB_CHECKSUMS. Do you guys think PKGBUILD-specific options would be useful? Say, something like --pkgver=$somever, so for trivial packages there'd be no need for further user intervention. You'd definitely have to rely on the beast called "sed" exclusively, though. Thanks and regards

3 3

[pacman-dev] Binary Database
by Dario Freddi 09 Mar '08

09 Mar '08

Hi everyone, I am writing this mail for a variety of reasons. First of all, some discussion in the forums, and then, because it's something that I've been thinking about for a long time. There have been many requests, AFAIK, for bringing pacman a binary database. Currently I'm writing a libalpm frontend, with some other guys (works in progress are @ KDEMod Forums), and we would really like to bring some improvements to Alpm, starting from its database. Every time this question arises (by doing a search through the forums), the answer is always "show us some code first". Well, nothing wrong with that, and unfortunately I have nothing to show now, but for a simple reason. Maybe I did not search well, but I still haven't found an answer to the following question: "Are pacman/alpm devs interested in having a binary database instead of the text based one?". If there is no interest, it would be useless to start coding. So I'd like to hear some voices/opinions. Then I will be more than happy to show some code. Cheers, Dario

2 1

[pacman-dev] Suggestion for a QUIET arg to makepkg
by Mark Constable 09 Mar '08

09 Mar '08

When it comes to using makepkg from a wrapper script, to build a series of packages, it would be good if there was an option to send logging to a file and not to STDOUT at the same time. This is just a suggestion and an example of one place where I need to patch my local makepkg. Perhaps this could be generalised via a VERBOSE arg instead where, for instance, VERBOSE=9 could be noisier than VERBOSE=1 (rather than just an on/off toggle). --markc --- /usr/bin/makepkg.orig 2008-02-21 01:52:39.000000000 +1000 +++ /usr/bin/makepkg 2008-02-21 02:04:31.000000000 +1000 @@ -58,6 +58,7 @@ SOURCEONLY=0 IGNOREARCH=0 HOLDVER=0 +QUIET=0 # Forces the pkgver of the current PKGBUILD. Used by the fakeroot call # when dealing with svn/cvs/etc PKGBUILDs. @@ -689,8 +690,11 @@ done mv "$BUILDLOG" "$BUILDLOG.$i" fi - - build 2>&1 | tee "$BUILDLOG"; ret=${PIPESTATUS[0]} + if [ "$QUIET" = "1" ]; then + build > "$BUILDLOG" 2>&1; ret=${PIPESTATUS[0]} + else + build 2>&1 | tee "$BUILDLOG"; ret=${PIPESTATUS[0]} + fi else build 2>&1 || ret=$? fi @@ -1069,6 +1073,7 @@ echo "$(gettext " -m, --nocolor Disable colorized output messages")" echo "$(gettext " -o, --nobuild Download and extract files only")" printf "$(gettext " -p <buildscript> Use an alternate build script (instead of '%s')")\n" "$BUILDSCRIPT" + echo "$(gettext " -q, --quiet Less verbose output to STDOUT")" echo "$(gettext " -r, --rmdeps Remove installed dependencies after a successful build")" # fix flyspray feature request #2978 echo "$(gettext " -R, --repackage Repackage contents of pkg/ without building")" @@ -1121,9 +1126,9 @@ SRCDEST=${SRCDEST:-$startdir} #default to $startdir if undefined # Parse Command Line Options. -OPT_SHORT="AbcCdefFghiLmop:rRsSV" +OPT_SHORT="AbcCdefFghiLmop:qrRsSV" OPT_LONG="ignorearch,asroot,builddeps,clean,cleancache,nodeps,noextract,force,forcever:,geninteg,help,holdver" -OPT_LONG="$OPT_LONG,install,log,nocolor,nobuild,rmdeps,repackage,source,syncdeps,usesudo,version" +OPT_LONG="$OPT_LONG,install,log,nocolor,nobuild,quiet,rmdeps,repackage,source,syncdeps,usesudo,version" # Pacman Options OPT_LONG="$OPT_LONG,noconfirm,noprogressbar" OPT_TEMP="$(getopt -o "$OPT_SHORT" -l "$OPT_LONG" -n "$(basename "$0")" -- "$@" || echo 'GETOPT GO BANG!')" @@ -1159,6 +1164,7 @@ -m|--nocolor) USE_COLOR='n' ;; -o|--nobuild) NOBUILD=1 ;; -p) shift; BUILDSCRIPT=$1 ;; + -q|--quiet) QUIET=1 ;; -r|--rmdeps) RMDEPS=1 ;; -R|--repackage) REPKG=1 ;; --source) SOURCEONLY=1 ;;

2 1

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-71-g91b7f28
by Dan McGee 09 Mar '08

09 Mar '08

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 91b7f288fe65b96d4af64f6308b0e33b14ad85e0 (commit) via fc48dc3118318d4b26b63a9453cd23cf2158cba3 (commit) via 51e0303e840c94e5943f30e311d053058f657327 (commit) via 2f9f48edddadffa2ac39ed7291f92be7be3b0fb5 (commit) via 1dfcf1495ba4c0ac36d770ef892483459e5678c4 (commit) via 724ed34ac5068bc3a44068ef4f831a431ca00346 (commit) via 74c5bd70cf97154f2fa09418bb87a9483a5359ff (commit) via 797c190f93d24ff1e352549f320a0612cd04382b (commit) via 3ec45486ff1373f9f65af229af315219fc1f0f7e (commit) via 266f06866bd56b86ca8525d2e07d48d08fedaa8f (commit) via 69eb0c80140380928e0b90889edd53608e127391 (commit) via 5a48771126992676b1e214f426698ad32c27869e (commit) via 54af52f87d6d9547629bb336c365943ff9bb4876 (commit) via 7c3f6feb41ef5ea99b1d0c94771210bf77d90c6d (commit) via 6ad4ba272dd50d021ebe5b5c3903d0181acd2e64 (commit) via 4a0498bd29804d4208de6d4e8977e2e40fe3ffb8 (commit) via 190d17c0e844c58bc1a1fa231b9aaf0c16dd686f (commit) via 8725dce2948f9e1eb9c6f9d66cdb5ef985e6de6c (commit) via 1bbc00cd9d7ff7b906e574f0ea669873f82ef550 (commit) via 8a24ad37549e6d06c1f3c6a469c82c0892fa8225 (commit) via 816b0805790238f4b6ab90b0d734bb68e1dc198a (commit) via 4c465ef0ad179622c40ce93ad103f057fb4f67a9 (commit) via 11bdab171e083a0668f1579c47accd9f632fe279 (commit) via 17eca54b321e4eed63cd27bfa3dbf960b0c96901 (commit) from 49197b7492d61bf1fc6bef59a708f4f586f32edb (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 91b7f288fe65b96d4af64f6308b0e33b14ad85e0 Merge: fc48dc3118318d4b26b63a9453cd23cf2158cba3 51e0303e840c94e5943f30e311d053058f657327 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 9 12:03:54 2008 -0500 Merge branch 'maint' Conflicts: configure.ac commit fc48dc3118318d4b26b63a9453cd23cf2158cba3 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Wed Feb 27 22:36:53 2008 +0100 Refactoring of the download code. This should be the main step in the download refactoring initiated by commit 81a2a06818d367f8528c74311171417beb9e1592. The stub functions introduced by that commit were implemented. The big download code was mostly composed of two steps, and so it has been naturally splitted in two functions : download_external and download_internal file:/// urls are now handled manually, instead of forcing the use of the internal downloader. Thanks to Dan for fixing the remaining issues and cleaning up the patch :) Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 74c5bd70cf97154f2fa09418bb87a9483a5359ff Author: Dan McGee <dan(a)archlinux.org> Date: Sat Mar 8 14:16:42 2008 -0600 Remove useless TESTS file This hasn't been updated in forever, and a simple python program could regenerate it anyway. Or even grep. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 797c190f93d24ff1e352549f320a0612cd04382b Author: Dan McGee <dan(a)archlinux.org> Date: Sun Dec 2 14:14:14 2007 -0600 Remove frontend add code that is no longer necessary Change the pacman_upgrade stub function to do what pacman_add used to do so we can eliminate pacman_add. Move the code to the more-descriptive name of upgrade.c. Note that we have made no changes to the backend libalpm, where an ADD type transaction could still be supported. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3ec45486ff1373f9f65af229af315219fc1f0f7e Author: Dan McGee <dan(a)archlinux.org> Date: Sun Dec 2 14:04:18 2007 -0600 Remove the Add option from the command line There is still a lot of code that could be cleaned up internally. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 266f06866bd56b86ca8525d2e07d48d08fedaa8f Author: Dan McGee <dan(a)archlinux.org> Date: Sat Mar 8 14:04:06 2008 -0600 Move -A pactests that are relevant to -U, clean the rest out This is in anticipation of removing the -A/--add option from the pacman frontend. I've went through each of the pacman pactests that used the -A operation and decided whether they were worth keeping, whether there was already an upgrade test doing the same thing, or whether it should be moved over. The GIT rename log should make several of the moves obvious, but for those that were deleted: add001: handled by upgrade004 add002: worthless add004: worthless add010: handled by upgrade011 add050: handled by upgrade010 Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: NEWS | 11 +- TRANSLATORS | 4 +- configure.ac | 4 +- contrib/PKGBUILD.vim | 30 +- contrib/README | 3 +- contrib/vimproject | 96 --- contrib/vimprojects | 25 + doc/pacman.8.txt | 7 - lib/libalpm/deps.c | 1 - lib/libalpm/dload.c | 586 +++++++++-------- lib/libalpm/po/Makevars | 2 +- lib/libalpm/po/cs.po | 225 +++----- lib/libalpm/po/de.po | 236 +++----- lib/libalpm/po/en_GB.po | 237 +++----- lib/libalpm/po/es.po | 228 +++----- lib/libalpm/po/fr.po | 221 +++---- lib/libalpm/po/hu.po | 501 ++++++-------- lib/libalpm/po/it.po | 221 +++---- lib/libalpm/po/libalpm.pot | 221 +++---- lib/libalpm/po/pl.po | 221 +++---- lib/libalpm/po/pt_BR.po | 221 +++---- lib/libalpm/po/ru.po | 221 +++---- lib/libalpm/po/zh_CN.po | 221 +++---- lib/libalpm/remove.c | 1 - pactest/Makefile.am | 3 +- pactest/tests/TESTS | 63 -- pactest/tests/add001.py | 13 - pactest/tests/add002.py | 18 - pactest/tests/add004.py | 18 - pactest/tests/add010.py | 15 - pactest/tests/add050.py | 17 - pactest/tests/depconflict110.py | 2 +- pactest/tests/depconflict111.py | 2 +- pactest/tests/fileconflict001.py | 2 +- pactest/tests/fileconflict002.py | 2 +- pactest/tests/ldconfig001.py | 2 +- pactest/tests/smoke001.py | 2 +- pactest/tests/{add003.py => upgrade005.py} | 2 +- pactest/tests/{add011.py => upgrade012.py} | 2 +- pactest/tests/{add012.py => upgrade013.py} | 2 +- pactest/tests/{add013.py => upgrade014.py} | 2 +- pactest/tests/{add020.py => upgrade015.py} | 2 +- pactest/tests/{add021.py => upgrade016.py} | 2 +- pactest/tests/{add060.py => upgrade070.py} | 2 +- pactest/tests/{add040.py => upgrade071.py} | 2 +- pactest/tests/{add041.py => upgrade072.py} | 2 +- pactest/tests/{add042.py => upgrade073.py} | 2 +- pactest/tests/{add046.py => upgrade074.py} | 2 +- pactest/tests/{add047.py => upgrade075.py} | 2 +- po/Makevars | 2 +- po/POTFILES.in | 2 +- po/cs.po | 541 ++------------- po/de.po | 539 ++------------- po/en_GB.po | 533 ++------------- po/es.po | 533 ++------------- po/fr.po | 546 +++------------- po/hu.po | 984 ++++++++-------------------- po/it.po | 548 +++------------- po/pacman.pot | 529 ++------------- po/pl.po | 533 ++------------- po/pt_BR.po | 533 ++------------- po/ru.po | 669 ++++--------------- po/zh_CN.po | 533 ++------------- src/pacman/Makefile.am | 2 +- src/pacman/conf.h | 2 - src/pacman/pacman.c | 77 ++- src/pacman/pacman.h | 9 +- src/pacman/{add.c => upgrade.c} | 34 +- src/util/testpkg.c | 48 +- 69 files changed, 2633 insertions(+), 8491 deletions(-) delete mode 100644 contrib/vimproject create mode 100644 contrib/vimprojects delete mode 100644 pactest/tests/TESTS delete mode 100644 pactest/tests/add001.py delete mode 100644 pactest/tests/add002.py delete mode 100644 pactest/tests/add004.py delete mode 100644 pactest/tests/add010.py delete mode 100644 pactest/tests/add050.py rename pactest/tests/{add003.py => upgrade005.py} (88%) rename pactest/tests/{add011.py => upgrade012.py} (90%) rename pactest/tests/{add012.py => upgrade013.py} (86%) rename pactest/tests/{add013.py => upgrade014.py} (89%) rename pactest/tests/{add020.py => upgrade015.py} (91%) rename pactest/tests/{add021.py => upgrade016.py} (92%) rename pactest/tests/{add060.py => upgrade070.py} (91%) rename pactest/tests/{add040.py => upgrade071.py} (89%) rename pactest/tests/{add041.py => upgrade072.py} (90%) rename pactest/tests/{add042.py => upgrade073.py} (91%) rename pactest/tests/{add046.py => upgrade074.py} (88%) rename pactest/tests/{add047.py => upgrade075.py} (88%) rename src/pacman/{add.c => upgrade.c} (87%) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-5-g51e0303
by Dan McGee 09 Mar '08

09 Mar '08

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 51e0303e840c94e5943f30e311d053058f657327 (commit) via 2f9f48edddadffa2ac39ed7291f92be7be3b0fb5 (commit) via 1dfcf1495ba4c0ac36d770ef892483459e5678c4 (commit) via 724ed34ac5068bc3a44068ef4f831a431ca00346 (commit) via 69eb0c80140380928e0b90889edd53608e127391 (commit) from 5a48771126992676b1e214f426698ad32c27869e (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: contrib/README | 3 +- contrib/vimproject | 96 ----------------------------------- contrib/vimprojects | 25 +++++++++ lib/libalpm/remove.c | 1 - po/ru.po | 136 +++++++++++++++++++++++++------------------------- src/pacman/pacman.c | 60 +++++++++++++++------- 6 files changed, 135 insertions(+), 186 deletions(-) delete mode 100644 contrib/vimproject create mode 100644 contrib/vimprojects hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] Use sigaction instead of signal.
by Chantry Xavier 09 Mar '08

09 Mar '08

>From signal man page : "The behavior of signal() varies across Unix versions, and has also varied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. See Portability below." The code was taken from there : http://www.gnu.org/software/libtool/manual/libc/Sigaction-Function-Example.… Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> --- src/pacman/pacman.c | 25 ++++++++++++++++++++----- 1 files changed, 20 insertions(+), 5 deletions(-) diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index f46b71c..9c56eae 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -212,7 +212,7 @@ static void cleanup(int ret) { * in a consistant state. * @param signum the thrown signal */ -static void handler(int signum) +static void termination_handler(int signum) { if(signum==SIGSEGV) { @@ -752,6 +752,7 @@ static int parseconfig(const char *file) int main(int argc, char *argv[]) { int ret = 0; + struct sigaction new_action, old_action; #if defined(HAVE_GETEUID) /* geteuid undefined in CYGWIN */ uid_t myuid = geteuid(); @@ -762,10 +763,24 @@ int main(int argc, char *argv[]) mtrace(); #endif - /* set signal handlers */ - signal(SIGINT, handler); - signal(SIGTERM, handler); - signal(SIGSEGV, handler); + /* Set signal handlers */ + /* Set up the structure to specify the new action. */ + new_action.sa_handler = termination_handler; + sigemptyset(&new_action.sa_mask); + new_action.sa_flags = 0; + + sigaction(SIGINT, NULL, &old_action); + if(old_action.sa_handler != SIG_IGN) { + sigaction(SIGINT, &new_action, NULL); + } + sigaction(SIGTERM, NULL, &old_action); + if(old_action.sa_handler != SIG_IGN) { + sigaction(SIGTERM, &new_action, NULL); + } + sigaction(SIGSEGV, NULL, &old_action); + if(old_action.sa_handler != SIG_IGN) { + sigaction(SIGSEGV, &new_action, NULL); + } /* i18n init */ #if defined(ENABLE_NLS) -- 1.5.4.2

3 2

[pacman-dev] Strange cleanup() function usage in pacman.c
by Nagy Gabor 09 Mar '08

09 Mar '08

Cleanup() is a signal handler. However, we usually pass some return values to it manually, see lines 816 and 822 for example. Or run pacman -V --debug. (parseargs returns with 2 == SIGINT) Is this OK?

4 4