- Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] Update the documentation of -Qs and -Ss
by Nagy Gabor 14 Jun '09

14 Jun '09

>From 26a3d52910e8c04794789bf2da7855a056a5886f Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Sun, 14 Jun 2009 21:00:07 +0200 Subject: [PATCH] Update the documentation of -Qs and -Ss It was undocumented that multiple regexps are interpreted using logical AND. Thanks to Recursive@#archlinux for his help. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- doc/pacman.8.txt | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index ca674ea..c8bedd2 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -233,7 +233,9 @@ Query Options[[QO]] *-s, \--search* <'regexp'>:: This will search each locally-installed package for names or - descriptions that match `regexp`. + descriptions that match `regexp`. When you include multiple search + terms, only packages with descriptions matching ALL of those terms will + be returned. *-t, \--unrequired*:: Restrict or filter output to packages not required by any currently @@ -317,7 +319,9 @@ linkman:pacman.conf[5]. *-s, \--search* <'regexp'>:: This will search each package in the sync databases for names or - descriptions that match `regexp`. + descriptions that match `regexp`. When you include multiple search + terms, only packages with descriptions matching ALL of those terms will + be returned. *-u, \--sysupgrade*:: Upgrades all packages that are out of date. Each currently-installed -- 1.6.0.3

1 0

[pacman-dev] [PATCH] Search package groups when searching a DB
by Dan McGee 13 Jun '09

13 Jun '09

See FS#13099. This makes sense especially for the pacman frontend, as we show groups in the search output. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- lib/libalpm/db.c | 13 +++++++++++-- 1 files changed, 11 insertions(+), 2 deletions(-) diff --git a/lib/libalpm/db.c b/lib/libalpm/db.c index 561967c..4bd55d2 100644 --- a/lib/libalpm/db.c +++ b/lib/libalpm/db.c @@ -397,10 +397,10 @@ alpm_list_t *_alpm_db_search(pmdb_t *db, const alpm_list_t *needles) else if (desc && regexec(&reg, desc, 0, 0, 0) == 0) { matched = desc; } - /* check provides */ /* TODO: should we be doing this, and should we print something * differently when we do match it since it isn't currently printed? */ - else { + if(!matched) { + /* check provides */ for(k = alpm_pkg_get_provides(pkg); k; k = k->next) { if (regexec(&reg, k->data, 0, 0, 0) == 0) { matched = k->data; @@ -408,6 +408,15 @@ alpm_list_t *_alpm_db_search(pmdb_t *db, const alpm_list_t *needles) } } } + if(!matched) { + /* check groups */ + for(k = alpm_pkg_get_groups(pkg); k; k = k->next) { + if (regexec(&reg, k->data, 0, 0, 0) == 0) { + matched = k->data; + break; + } + } + } if(matched != NULL) { _alpm_log(PM_LOG_DEBUG, " search target '%s' matched '%s'\n", -- 1.6.3.2

3 3

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.2-178-gf250b03
by dan＠archlinux.org 13 Jun '09

13 Jun '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 f250b034b407d45bb08c7b713b01d25e0bb2b6ee (commit) via ef500b44ce45255da16e18b8e9aa4d43fab359b8 (commit) via 04d5c4294ab5d35cceb149d7c94a4bf3aa6d7a85 (commit) from aa579b843899ccba093f83faa942599ce1110c24 (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 f250b034b407d45bb08c7b713b01d25e0bb2b6ee Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Wed Jun 10 20:22:04 2009 +0200 Enable remove progressbar with -S (conflict resolving) $ sudo pacman -S mc Old output: *********** :: mc conflicts with mc-mp. Remove mc-mp? [Y/n] y ... (1/1) checking for file conflicts [################] 100% (1/1) installing mc [################] 100% New output: *********** :: mc conflicts with mc-mp. Remove mc-mp? [Y/n] y ... (1/1) checking for file conflicts [################] 100% (1/1) removing mc-mp [################] 100% (1/1) installing mc [################] 100% Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ef500b44ce45255da16e18b8e9aa4d43fab359b8 Author: Allan McRae <allan(a)archlinux.org> Date: Tue Jun 9 14:11:15 2009 +1000 makepkg: fix variable backup/restore for splitpkg The backup and restore of variables that can be overridden while making split packages only dealt with the first element, not the whole array (FS#15010). Adjust the bash voodoo to fix it... Signed-off-by: Allan McRae <allan(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 04d5c4294ab5d35cceb149d7c94a4bf3aa6d7a85 Author: Allan McRae <allan(a)archlinux.org> Date: Sat Jun 13 23:54:23 2009 +1000 makepkg: fix PKGBUILD sanity check If PKGBUILD was good, the "insane" variable was not defined and so the if statement failed. Simplify and fix this check. Signed-off-by: Allan McRae <allan(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/sync.c | 1 + scripts/makepkg.sh.in | 9 +++------ 2 files changed, 4 insertions(+), 6 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] makepkg: fix PKGBUILD sanity check
by Allan McRae 13 Jun '09

13 Jun '09

If PKGBUILD was good, the "insane" variable was not defined and so the if statement failed. Simplify and fix this check. Signed-off-by: Allan McRae <allan(a)archlinux.org> --- scripts/makepkg.sh.in | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index e2e1604..433fe34 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1630,10 +1630,7 @@ if [ "$(type -t package)" = "function" ]; then fi # check the PKGBUILD for some basic requirements -check_sanity || insane=1 -if [ $insane -eq 1 ]; then - exit 1 -fi +check_sanity || exit 1 # We need to run devel_update regardless of whether we are in the fakeroot # build process so that if the user runs makepkg --forcever manually, we -- 1.6.3.2

2 1

Re: [pacman-dev] [arch-general] Package groups
by Xavier 13 Jun '09

13 Jun '09

On Fri, Jun 12, 2009 at 9:44 PM, Aaron Griffin<aaronmgriffin(a)gmail.com> wrote: > On Fri, Jun 12, 2009 at 2:32 PM, Grigorios Bouzakis<grbzks(a)gmail.com> wrote: >> Is it OK for a package in [community] to be part of a package group? >> AFAIK package groups dont exist in [community] or if they do they are >> not the same >> as the ones in extra. >> eg. http://bugs.archlinux.org/task/15053 >> http://repos.archlinux.org/viewvc.cgi/community/gnome/empathy/PKGBUILD?view… >> empathy gets to be part of gnome-extra > > Yeah, as far as I know, this shouldn't happen, as it breaks "pacman -S > gnome-extra" in a way > I don't think it is a problem. pacman will just ask for each repo if you want to install the packages of the group, but it is fine.

1 0

[pacman-dev] My "universal" git repo
by Nagy Gabor 11 Jun '09

11 Jun '09

Hi! http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal I've managed to implement some nice features for -U by "moving" upgrade_prepare to sync.c. 1. Conflict resolving should now work (upgrade051.py now passes), FS#3492 implemented. (This was my main motivation.) 2. -U --syncdeps now can resolve dependencies by downloading and installing them from sync repos. In this case, pacman can skip unresolvable targets like with -S. If this patch is going to be accepted, I ask everyone to test "pacman-universal" extensively (there are some changes in UI as well!), because sync.c is quite complex, so it has a chance that I broke something there (and this is a "radical" change, this is a big responsibility). There are no failing pactests, which is a good starting point. Bye

3 3

Re: [pacman-dev] My "universal" git repo
by Nagy Gabor 11 Jun '09

11 Jun '09

> Nagy Gabor wrote: > > Hi! > > > > http://repo.or.cz/w/pacman-ng.git?a=shortlog;h=refs/heads/universal > > > > I've managed to implement some nice features for -U by "moving" > > upgrade_prepare to sync.c. > > > > 1. Conflict resolving should now work (upgrade051.py now passes), > > FS#3492 implemented. (This was my main motivation.) > > 2. -U --syncdeps now can resolve dependencies by downloading and > > installing them from sync repos. In this case, pacman can skip > > unresolvable targets like with -S. > > > > If this patch is going to be accepted, I ask everyone to test > > "pacman-universal" extensively (there are some changes in UI as well!), > > because sync.c is quite complex, so it has a chance that I broke > > something there (and this is a "radical" change, this is a big > > responsibility). There are no failing pactests, which is a good starting > > point. > > > > I had a quick look at the patches and I like what is done. One part > that confuses me is: > > @@ -460,7 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=1629171ba7…> > +462,12 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=690001fe3d…> > @@ static int parseargs(int argc, char *argv[]) > case 'R': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_REMOVE); break; > case 'S': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_SYNC); break; > case 'T': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_DEPTEST); break; > - case 'U': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_UPGRADE); break; > + case 'U': > + config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_UPGRADE); > + if(!config->op_u_syncdeps) { > + config->flags |= PM_TRANS_FLAG_NORESOLVEDEPS; > + } > + break; > case 'V': config->version = 1; break; > case 'b': > config->dbpath = strdup(optarg); > @@ -506,6 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=1629171ba7…> > +513,8 > <http://repo.or.cz/w/pacman-ng.git?a=blob;f=src/pacman/pacman.c;h=690001fe3d…> > @@ static int parseargs(int argc, char *argv[]) > } else { > config->flags |= PM_TRANS_FLAG_RECURSE; > } > + config->op_u_syncdeps = 1; > + config->flags &= ~PM_TRANS_FLAG_NORESOLVEDEPS; > break; > case 't': > config->op_q_unrequired = 1; > > > So the "case U:" part sets PM_TRANS_FLAG_NORESOLVEDEPS by default and > then the "case s:" makes sure it is not set? Or am I reading that wrong > (binary operators and me are not friends...). -U sets that flag (if -s was not invoked before, this check is because of -sU should do the same), -s unsets that flag. > Would it not be better to use "PM_TRANS_FLAG_RESOLVEDEPS" and then "case > U" stays the same, "case s:" sets it. I suppose that would make the > test in _alpm_sync_prepare more difficult. You are right here, this codepart would look better with PM_TRANS_FLAG_RESOLVEDEPS. I decided to go with NORESOLVEDEPS, because RESOLVEDEPS is the default behavior (for -S), and usually we have a flag for the non-default setting (NODEPS, NOCONFLICTS etc). With RESOLVEDEPS, that flag should be always passed with -S. > Or (my favourite), get rid of this altogether and just assume the deps > are to be resolved by default and expect "-Ud" if someone does not want > that to be done? I can not see a reason someone would not want to sync > deps if there are not already installed and it makes the -U and -S > operations even more universal. Yes, I was also thinking about this, but I decided to keep the old default behaviour as much as possible. [Btw, we have a hidden API change here, alpm front-ends have to pass PM_TRANS_FLAG_NORESOLVEDEPS with -U to keep the old behavior.] If Dan also prefers your way, I will happily implement that (because the code would be nicer, indeed). Bye

1 0

[pacman-dev] [PATCH] Enable remove progressbar with -S (conflict resolving)
by Nagy Gabor 11 Jun '09

11 Jun '09

>From 0880c6a0f60e8377197f00bd5fab3652a3e40f39 Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Wed, 10 Jun 2009 20:22:04 +0200 Subject: [PATCH] Enable remove progressbar with -S (conflict resolving) $ sudo pacman -S mc Old output: *********** :: mc conflicts with mc-mp. Remove mc-mp? [Y/n] y ... (1/1) checking for file conflicts [################] 100% (1/1) installing mc [################] 100% New output: *********** :: mc conflicts with mc-mp. Remove mc-mp? [Y/n] y ... (1/1) checking for file conflicts [################] 100% (1/1) removing mc-mp [################] 100% (1/1) installing mc [################] 100% Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/sync.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index d366ee1..c7ac966 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -942,6 +942,7 @@ int _alpm_sync_commit(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t **data) } /* we want the frontend to be aware of commit details */ tr_remove->cb_event = trans->cb_event; + tr_remove->cb_progress = trans->cb_progress; if(_alpm_trans_commit(tr_remove, NULL) == -1) { _alpm_log(PM_LOG_ERROR, _("could not commit removal transaction\n")); goto error; -- 1.6.0.3

2 1

[pacman-dev] [PATCH] makepkg: fix variable backup/restore for splitpkg
by Allan McRae 09 Jun '09

09 Jun '09

The backup and restore of variables that can be overridden while making split packages only dealt with the first element, not the whole array (FS#15010). Adjust the bash voodoo to fix it... Signed-off-by: Allan McRae <allan(a)archlinux.org> --- 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 f46b7f8..e2e1604 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1262,7 +1262,7 @@ devel_update() { backup_package_variables() { for var in ${splitpkg_overrides[@]}; do indirect="${var}_backup" - eval "${indirect}=\"${!var}\"" + eval "${indirect}=(\${$var[@]})" done } @@ -1270,7 +1270,7 @@ restore_package_variables() { for var in ${splitpkg_overrides[@]}; do indirect="${var}_backup" if [ -n "${!indirect}" ]; then - eval "${var}=\"${!indirect}\"" + eval "${var}=(\${$indirect[@]})" else unset ${var} fi -- 1.6.3.2

2 2

[pacman-dev] Pacman "Roadmap"
by Allan McRae 09 Jun '09

09 Jun '09

Hi everybody, Over the past year, various discussions have occurred about nice features to be included in pacman, but many have not yet been implemented. So they didn't get lost, I made a small wiki page with them: http://wiki.archlinux.org/index.php/Pacman_Roadmap Of course there are many other areas to improve (see bug tracker...), but I tried to select "big" features that someone could probably make a reasonable start on without knowing the pacman code base by heart. I.e. features big enough to warrant a 3.x release and not a 4.0 one. Feel free to add ideas in that category that I have missed but remember all discussion of new ideas should occur on this list first... Cheers, Allan

1 0