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

[pacman-dev] alpm_list regex matching
by leslie.polzer＠gmx.net 12 Apr '09

12 Apr '09

Hello, inlined diff (p0, hope that's not a problem) adds regex matching to alpm_list; useful for regular expressions in IgnorePkg etc. I'll leave the actual usage up to you and hope it helps somehow :) Leslie -- NEW homepage: https://viridian.dnsalias.net/~sky/homepage/ gpg --keyserver pgp.mit.edu --recv-keys DD4EBF83 Index: lib/libalpm/alpm_list.c =================================================================== RCS file: /home/cvs-pacman/pacman-lib/lib/libalpm/alpm_list.c,v retrieving revision 1.11 diff -a -p -u -r1.11 alpm_list.c --- lib/libalpm/alpm_list.c 11 Mar 2007 21:10:03 -0000 1.11 +++ lib/libalpm/alpm_list.c 14 Apr 2007 19:18:15 -0000 @@ -24,9 +24,11 @@ #include <stdlib.h> #include <string.h> #include <stdio.h> +#include <regex.h> /* libalpm */ #include "alpm_list.h" +#include "error.h" #include "util.h" /** \defgroup alpm_list functions */ @@ -458,6 +460,39 @@ int SYMEXPORT alpm_list_find_str(alpm_li return(0); } +/* Test for existence of a string in an alpm_list_t, treating the list + * elements as regular expressions +*/ +/** Is a _string_ in the list (optimization of alpm_list_find for strings) + * @param needle the string to compare + * @param haystack the list to search + * @return 1 if `needle` is found, 0 otherwise + */ + +int SYMEXPORT alpm_list_find_str_regex(alpm_list_t *haystack, const char *needle) +{ + alpm_list_t *lp = haystack; + + while(lp) { + if(lp->data) { + char* targ = lp->data; + regex_t reg; + + _alpm_log(PM_LOG_DEBUG, "matching needle '%s' against haystack item '%s'", + needle, lp->data); + + if(regcomp(&reg, targ, REG_EXTENDED | REG_NOSUB | REG_ICASE | REG_NEWLINE) != 0) { + RET_ERR(PM_ERR_INVALID_REGEX, NULL); + } + + if (regexec(&reg, needle, 0, 0, 0) == 0) { + return(1); + } + } + lp = lp->next; + } + return(0); +} /** * Calculate the items in list `lhs` that are not present in list `rhs` * @note Entries are not duplicated

3 2

[pacman-dev] [patch] add support for scriptlets functions embedded in $BUILDSCRIPT
by Alessio 'mOLOk' Bolognino 26 Feb '08

26 Feb '08

Hi, I think there isn't a real need to split PKGBUILD and $pkgname.install, this patch allows you to put the scriptlets functions into the PKGBUILD. This IMHO follows the KISS philosophy. If at least a {post,pre}_{install,upgrade,remove} function is found in the PKGBUILD, then the install file (if it exists) is ignored; otherwise, if there isn't any scriptlet function in the PKGBUILD the install file is included, as usually. Enjoy: From e206a96ebe1e9a11f85de1502fc46e75321ba192 Mon Sep 17 00:00:00 2001 From: Alessio 'mOLOk' Bolognino <themolok(a)gmail.com> Date: Sat, 21 Jul 2007 06:15:34 +0200 Subject: [PATCH] Added support for scriptlets functions embedded in $BUILDSCRIPT --- scripts/makepkg.sh.in | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index a3e4d9c..fb931a7 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -831,9 +831,18 @@ create_package() { local comp_files=".PKGINFO .FILELIST" - # check for an install script + # check for scriptlets fuctions or an install script # TODO: should we include ${pkgname}.install if it exists and $install is unset? - if [ "$install" != "" ]; then + scriptlet=$(declare -f {post,pre}_{install,remove,upgrade} || return 0) + if [ "$scriptlet" != "" ]; then + msg2 "$(gettext "Adding scriptlet functions (install script will be ignored)...")" + ( echo "$scriptlet" + echo 'op=$1' + echo 'shift' + echo '[ "$(type -t "$op")" = "function" ] && $op "$@"' + ) > .INSTALL + comp_files="$comp_files .INSTALL" + elif [ "$install" != "" ]; then msg2 "$(gettext "Adding install script...")" cp "$startdir/$install" .INSTALL comp_files="$comp_files .INSTALL" @@ -1175,6 +1184,7 @@ fi unset pkgname pkgver pkgrel pkgdesc url license groups provides md5sums force unset replaces depends conflicts backup source install build makedepends unset options noextract +unset {post,pre}_{install,remove,upgrade} if [ ! -f "$BUILDSCRIPT" ]; then error "$(gettext "%s does not exist.")" "$BUILDSCRIPT" -- 1.5.2.4 -- Alessio 'mOLOk' Bolognino Arch Linux Trusted User Please send personal email to themolok(a)gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB

9 20

[pacman-dev] dbs should be locked between _alpm_db_open and _alpm_db_close
by Nagy Gabor 28 Oct '07

28 Oct '07

Hi! The problem bellow doesn't appear with the current dummy front-end, but if you want to design a flexible alpm lib, you have to deal with it. The main problem, that the whole pkgcache concept _assumes_ that the db won't be modified by other processes. However, pacman locks db iff he modifies it, so he cannot trust his assumption. Let me explain. Imagine a nice pacman GUI which starts with alpm_initialize, opens the databases and let user do multiple operations. pacman_gui can run all the day, without unregistering the databases, alpm_release etc. etc. The main problem, that if pacman_gui (== libalpm) let an other pacman instance to modify the local db, he should always reload the pkgcache, because it may be outdated! So the following situation can happen: pacman_gui loaded the pkgcache to list the available local packages to the user, and now he is waiting. During this an other pacman instance removed lot of packages (he could lock anf unlock the db, since pacman_gui didn't lock anything yet) and exited. pacman_gui didn't detect anything from this. Now the user ask pacman_gui to install some packages: now he locks the dbs, but he trust its outdated pkgcache: for example its depchecks will use this outdated information... So _alpm_db_open should lock database, and _alpm_db_close should unlock it. The problem here, that now a non-root user cannot write /var/lib/pacman/local/db.lck, but we can solve this somehow. (Note, that I'm suggesting a lock-per-db method here.) Another (not-so-strict but slower) possible solution a .lastupdate-like method to detect if the database was modified or not after pkgcache load, and reload if needed. Bye, ngaba ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

2 2

[pacman-dev] fglrx-utils preferred over libgl-dri
by Alexander Baldeck 20 Oct '07

20 Oct '07

Hey all, I was just about to upgrade oxine and it used to only depend on xine-lib. xine-lib pulls a great deal of xorg stuff but then one strange thing happened. pacman felt like fglrx-utils would be the right package to pull to fulfill the requirement of 'libgl' on the system. Now I would like to not have that, what would happen if I were to go and change pkgname of libgl-dri to just libgl since Jan dropped libgl-mesa long ago? Pacman should prefer the real pkgname over provides, right? Cheers, -J

5 12

[pacman-dev] RootDir using symlinks -> problem
by Xavier 17 Oct '07

17 Oct '07

I use the following options for using an alternate rootdir and testing stuff: RootDir = /home/xav/pacman/pacman/foo DBPath = /home/xav/pacman/pacman/foo/var/lib/pacman CacheDir = /home/xav/pacman/pacman/foo/var/cache/pacman/pkg with the following symlink : /home/xav/pacman -> /data/share/devel/pacman/ Running pacman -v with this config gives the following : Root : /data/share/devel/pacman/pacman/foo/ DB Path : /home/xav/pacman/pacman/foo/var/lib/pacman/ This makes the scriptlets handling in libalpm/trans.c break : 570 strncpy(scriptfn, installfn, PATH_MAX); 571 /* chop off the root so we can find the tmpdir in the chroot */ 572 scriptpath = scriptfn + strlen(root) - 1; Because for example: scriptfn = /home/xav/pacman/pacman/foo/var/lib/pacman/local/slocate-3.1-3/install root = /data/share/devel/pacman/pacman/foo/ so scriptpath result in /pacman/local/slocate-3.1-3/install, instead of /var/lib/pacman/local/slocate-3.1-3/install

4 19

[pacman-dev] Future pacman development (3.2/4.0)
by Dan McGee 09 Oct '07

09 Oct '07

Here is a little email to get ideas flowing on what will follow the 3.1 release in pacman development. I might as well start it off with a bang by saying I think pacman (and especially libalpm) would be best if it got a full cleansing and rewrite. This is one of those things that is just tough to do, but I think all of us can see the benefits in doing it. We've seen where our current interface is a bit lacking, and we could find many ways to improve on that. There would also be the ability to rewrite pacman to be much more efficient in some of the operations that are currently the bottlenecks (namely lists). Lists could be replaced by hash tables in a few places (package caches?), and in other places we could simply use better list structures in order to navigate them more efficiently. I really like the idea of using a kernel list implementation to do this, as it would enforce typing. However, the details of that may need to be reasonably well hidden inside the library. If we were to do a rewrite, I think the best way would be to do it slowly and one piece at a time. Start with the backend interface and slowly build from there, setting interfaces at each level. Much of the code could be gleaned from the existing codebase, but scrutinized a bit to ensure it is of good quality and doing things the way we want to. Other code would end up in some burning inferno somewhere never to be seen again, which would make me more than happy. If we don't do a full rewrite, something that really needs looking at is the list data structures we use. alpm_list_last (called by alpm_list_add) is a huge bottleneck, consuming 40% of the time in a pacman -Su operation from start to when you are presented with the package list to install. That is pretty pathetic. A pacman -Qo operation is another great example of the inefficiency of the existing list structure. Thoughts and comments welcome. -Dan

8 31

[pacman-dev] -Qu vs -Su
by Xavier 05 Oct '07

05 Oct '07

Since the discussion on http://bugs.archlinux.org/task/7884 is confusing me, I thought I would bring it here. The issue reported by Dan is the following : The -Qu output is different than -Su one, because -Su resolves dependencies, while -Qu does not. My first question : is that really an issue? The description of -Qu says : -u, --upgrades list all packages that can be upgraded IMO, a new dependency does not belong to the list of packages that can be upgraded. So it isn't necessarily a bug if it shows up in -Su, but not in -Qu. Also, note that -Qu can't match exactly -Su, because -Su is interactive : Replace %s with %s/%s? [Y/n] %s conflicts with %s. Remove %s? [Y/n] But if you answer no to the conflicts question, pacman just fails and stops there. So not very interesting. And the replace question is generally answered by yes. So answering yes to both questions should give a good picture of what will happen.

6 20

[pacman-dev] [GIT] pacman branch, master now at v3.0.0-434-g48bf088
by Aaron Griffin 05 Oct '07

05 Oct '07

Hello, This is an automated email from the git hooks/update script, it was generated because a ref change was pushed to the repository. Updating branch, master, via 48bf088e65403049dc430fadf360355a8d5dc07d (commit) via b86479cf9b584c62dbda967902cee2a81678c9ef (commit) via 4942d216323cbe2f099c43893cc95368a3cd1197 (commit) via 50bb16e0151e31479cb2602c9749ffe18f7a3592 (commit) via cb3c3a920d976942fbc72b2d9dbff5320ca9415c (commit) via f2f4ada1d6cfee83674684b948e5698049479f95 (commit) via 47622eef4dd8fd86a0aa0e3ebdb7b33f7c9d6804 (commit) from 219808714f94788a66a430786c552f60e95b1a01 (commit) - Log ----------------------------------------------------------------- commit 48bf088e65403049dc430fadf360355a8d5dc07d Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Thu Sep 27 23:38:51 2007 -0500 Use ANSI 'foreground' color instead of hardcoding 'white' Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit b86479cf9b584c62dbda967902cee2a81678c9ef Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Thu Sep 27 23:04:00 2007 -0500 Allow --refresh specified for most -S options Included options are -g, -i, -s, and -l All of these will sync the DB if -y is specified and permissions are appropriate. Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit 4942d216323cbe2f099c43893cc95368a3cd1197 Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Thu Sep 27 23:03:35 2007 -0500 Break out transaction test to a separate function Added needs_transaction, putting out "hey do we need root?" tests in one place. Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit 50bb16e0151e31479cb2602c9749ffe18f7a3592 Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Thu Sep 27 21:38:47 2007 -0500 OMG a space! Yeah, I added a space. It deserves its own commit. Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit cb3c3a920d976942fbc72b2d9dbff5320ca9415c Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Thu Sep 27 21:18:06 2007 -0500 Minor "cannot remove" message cleanup The strings differed in quotes only, this way we have only one i18n string for translation Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit f2f4ada1d6cfee83674684b948e5698049479f95 Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Wed Sep 19 00:25:38 2007 -0500 Remove buildtype package accessor prototype This was removed a while ago, but the prototype was still hanging out. Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> commit 47622eef4dd8fd86a0aa0e3ebdb7b33f7c9d6804 Author: Aaron Griffin <aaronmgriffin(a)gmail.com> Date: Wed Sep 19 00:21:56 2007 -0500 Support for localized times in metadata Packages and DBs now support using the UNIX epoch (seconds since Jan 1, 1970) for use in builddate and installdate. This will only affect newly built packages. Old existing packages with the text format are still supported, but this is deprecated. In the case of removal of text time support, this code will fail gracefully, returning the start of the epoch for broken packages. Signed-off-by: Aaron Griffin <aaronmgriffin(a)gmail.com> ----------------------------------------------------------------------- Diffstat: lib/libalpm/add.c | 5 +--- lib/libalpm/alpm.h | 5 +-- lib/libalpm/be_files.c | 38 ++++++++++++++++++++++++++++------- lib/libalpm/package.c | 16 ++++++++------ lib/libalpm/package.h | 4 +- lib/libalpm/remove.c | 3 +- scripts/makepkg.sh.in | 12 +++++----- src/pacman/package.c | 7 +++-- src/pacman/pacman.c | 20 +++--------------- src/pacman/sync.c | 51 +++++++++++++++++++++++++---------------------- src/pacman/util.c | 19 +++++++++++++++++ src/pacman/util.h | 1 + 12 files changed, 107 insertions(+), 74 deletions(-) hooks/update --- Git Source Code Management System hooks/update refs/heads/master \ 219808714f94788a66a430786c552f60e95b1a01 \ 48bf088e65403049dc430fadf360355a8d5dc07d

3 4

[pacman-dev] new failing pactest file: sync1004.py
by Nagy Gabor 03 Oct '07

03 Oct '07

Hi! I post this pactest as a motivation to review my patches ;-) This is the rewrite of sync1003.py to a more common case. Bye, ngaba ==sync1004.py== self.description = "Induced removal would break dependency (2)" sp1 = pmpkg("pkg1") sp1.conflicts = [ "depend" ] self.addpkg2db("sync", sp1) sp2 = pmpkg("pkg2") sp2.depends = ["depend"] self.addpkg2db("sync", sp2) lp = pmpkg("depend") self.addpkg2db("local", lp) self.args = "-S pkg1 pkg2" self.addrule("PACMAN_RETCODE=1") self.addrule("PKG_EXIST=depend") ---------------------------------------------------- SZTE Egyetemi Könyvtár - http://www.bibl.u-szeged.hu This mail sent through IMP: http://horde.org/imp/

3 2

[pacman-dev] Several output issues
by Xavier 29 Sep '07

29 Sep '07

I wonder if the output of this mail won't be a problem in itself, but well I'll give it a try at least. While using pacman 3.1 , I've noticed several issues with the output. Unfortunately I wasn't able to debug any of them, but thought I would share them anyway, in case someone has a clue. I noticed mostly two kinds of issues : 1) Issues with the messages / notifications from src/pacman/callback.c > $ sudo LANG=C pacman -S xf86-video-i810 > resolving dependencies... done. > :: xf86-video-i810 conflicts with xf86-video-intel. Remove xf86-video-intel? [Y/n] looking for inter-conflicts... > done. > > Remove: xf86-video-intel > > Total Removed Size: 0.10 MB > Targets: xf86-video-i810-1.7.4-6 > Total Package Size: 3.55 MB > Total Installed Size: 9.87 MB > Proceed with installation? [Y/n] That "looking for inter-conflicts..." message looks a bit weird there. > $ sudo LANG=C pacman -S xterm > :: xterm-229-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: xterm-229-2 > > Total Package Size: 0.20 MB > > Proceed with installation? [Y/n] > :: Archive xterm-229-2.pkg.tar.gz is corrupted. Do you want to delete it? [Y/n] checking package integrity... > error: failed to commit transaction (corrupted package) > archive xterm-229-2.pkg.tar.gz was corrupted (bad MD5 checksum) > Errors occurred, no packages were upgraded. Same for "checking package integrity..." here. 2) Issues with the progress bar (used in remove_commit and commit_single_pkg) > $ sudo LANG=C pacman -R xorg-xinit xorg-twm > loading package data... checking dependencies... done. > warning: /etc/X11/twm/system.twmrc saved as /etc/X11/twm/system.twmrc.pacsave > (1/2) removing xorg-twm [############################] 100% > warning: /etc/skel/.xinitrc saved as /etc/skel/.xinitrc.pacsave------------------] 0% > (2/2) removing xorg-xinit [############################] 100 > $ sudo LANG=C pacman -S xorg-xinit xorg-twm > :: xorg-xinit-1.0.5-1: local version is up to date. Upgrade anyway? [Y/n] > :: xorg-twm-1.0.1-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: xorg-xinit-1.0.5-1 xorg-twm-1.0.1-2 > > Total Package Size: 0.10 MB > > Proceed with installation? [Y/n] > checking package integrity... done. > (2/2) checking for file conflicts [############################] 100% > (1/2) upgrading xorg-xinit [############################] 100% > warning: /etc/X11/twm/system.twmrc installed as /etc/X11/twm/system.twmrc.pacnew-] 0% > (2/2) upgrading xorg-twm [############################] 100 > $ sudo LANG=C pacman -S filesystem > :: filesystem-2007.08-2: local version is up to date. Upgrade anyway? [Y/n] > resolving dependencies... done. > looking for inter-conflicts... done. > > Targets: filesystem-2007.08-2 > > Total Package Size: 0.10 MB > > Proceed with installation? [Y/n] > checking package integrity... done. > (1/1) checking for file conflicts [############################] 100% > warning: directory permissions differ on proc/ [----------------------------] 0% > filesystem: 555 package: 755(1/1) upgrading filesystem [############################] 100% That last one is a bit particular, I think it was missed during that last newline commit : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=5c9eec5570c145c0… But after adding newlines, it just behaves like the above ones, the messages end with a progressbar, and it looks rather odd. I think I see at least 2 workarounds for this problem : * totally disable all these warnings during extraction * buffer the messages, and display them only after all the files have been extracted. There might be a better solution that doesn't require any of these though. Wouldn't it be possible to just clear the line before outputting the messages, or something like that, and let the progress bar redisplay itself on the next line?

2 8