- Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] The official pacman repository annotated tag, v3.1.4, created. v3.1.4
by Dan McGee 02 Apr '08

02 Apr '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 annotated tag, v3.1.4 has been created at 683b4ce6daf7d4a9c754add6901f69ff6ead7ca4 (tag) tagging 0b8abf376f4a34d18aed450642284d9410522667 (commit) replaces v3.1.3 tagged by Dan McGee on Tue Apr 1 22:08:24 2008 -0500 - Log ----------------------------------------------------------------- Fix-a-roo bee doo compiled/tested with gcc-4.3 * 8 pactest failures (all expected) compiled/tested with gcc-3.4 * 8 pactest failures (all expected) Look at the symmetry in those compiler versions! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) iEYEABECAAYFAkfy+K0ACgkQXC5GoPU6du1nagCdEbKEcrEiPLN2XgeExDoj06Ea iCsAn2GbtnKoGVLghdRWe33Kv4IBOzF/ =4UQM -----END PGP SIGNATURE----- Chantry Xavier (7): rename vimproject to vimprojects and update it. src/pacman/pacman.c : split cleanup function. Use sigaction instead of signal. Clarify the NoUpgrade and NoExtract behavior. PKGBUILD.vim: improve invalid arch/license detection. PKGBUILD.vim: add keepend keyword for sha1/md5 fields Duplicate the result of archive_entry_pathname. Dan McGee (5): strsplit(): memleak fix memleak fix: ensure backup fname isn't lost if unused Fix manpage typo Set handle->logstream to null after fclose() Update NEWS and configure.ac for 3.1.4 release Nagy Gabor (3): Remove a bogus comment from libalpm/remove.c Show options in pacman.conf (commented out) Use pkgcache instead of db_scan in remove.c Sergey Tereschenko (1): Updates to Russian translation 甘露(Lu.Gan) (2): po/zh_CN.po: Chinese Simplified translation update Updates to Simplified Chinese translation ----------------------------------------------------------------------- hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-18-g0b8abf3
by Dan McGee 02 Apr '08

02 Apr '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 0b8abf376f4a34d18aed450642284d9410522667 (commit) from ab9187d07de03e6545881a72180e76e728317bb9 (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: NEWS | 4 ++++ configure.ac | 4 ++-- contrib/Makefile.am | 2 +- po/ru.po | 12 ++++-------- 4 files changed, 11 insertions(+), 11 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-109-g073bac7
by Dan McGee 02 Apr '08

02 Apr '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 073bac794d7643fae21dacbe3d5c1585ce347bea (commit) via 0b8abf376f4a34d18aed450642284d9410522667 (commit) via ab9187d07de03e6545881a72180e76e728317bb9 (commit) from 0bd6fb3bc28b395d5af099221e2c0401d3be42e2 (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 073bac794d7643fae21dacbe3d5c1585ce347bea Merge: 0bd6fb3bc28b395d5af099221e2c0401d3be42e2 0b8abf376f4a34d18aed450642284d9410522667 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Apr 1 22:14:58 2008 -0500 Merge branch 'maint' Conflicts: configure.ac contrib/Makefile.am ----------------------------------------------------------------------- Summary of changes: NEWS | 4 ++++ configure.ac | 2 +- contrib/Makefile.am | 2 +- lib/libalpm/handle.c | 1 + po/ru.po | 12 ++++-------- 5 files changed, 11 insertions(+), 10 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-17-gab9187d
by Dan McGee 02 Apr '08

02 Apr '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 ab9187d07de03e6545881a72180e76e728317bb9 (commit) from d9b9e60d7d4943ec0395a66bd40d22089cfbee35 (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 ab9187d07de03e6545881a72180e76e728317bb9 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Apr 1 17:44:30 2008 -0500 Set handle->logstream to null after fclose() We correctly closed the logfile stream when recalling set_logfile, but did not NULL out the dead pointer once we did this. Fix the problem which was the cause of FS#10056. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/handle.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [ANNOUNCE] libpmpmmm 1.0-479-gb2c39e6
by Miklos Vajna 01 Apr '08

01 Apr '08

Hi Guys, I would like to announce something that we have been working on during the last few months. First, let me explain what libpmpmmm stands for, though I'm quite sure you all know what it is. Poor man's package manager library, written in C++. You probably all remember to the new function names like alpm_pkg_getinfo() and the mess with return types. Now this is no longer a problem using C++, there are multiple alpmPkgGetinfo() functions and you can write multiple backends to determine which one will be executed. I know you all hate C++, so we wrote Java bindings, this way you can implement your own backends in Java as well. Oh well, there is an experimental C# binding as well, but that's not yet public. So far we implemented one backend, it uses a random algorithm as we think the method C++ uses (polymorphism) is boring. At the moment the random generator returns constant 4, to help testing. We talked to Richard Stallman when we choosed the license, he suggested to CDDL as GNU Autotools will use that license soon, so all projects using GNU Autotools and GPL will be illegal. Download: git clone git://git.frugalware.org/pub/other/libpmpmmm/libpmpmmm Please keep in mind that at the moment you can't replace libalpm with libpmpmm due to patent issues, but we are working on that problem. Oh, forgot to mention. Our patent is about we use a technology to change the API without rebuilding the library. This closes FS#7947, FS#9307. Oops, and FS#9005 as well. Have a nice day!

6 8

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-106-g0bd6fb3
by Dan McGee 31 Mar '08

31 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 0bd6fb3bc28b395d5af099221e2c0401d3be42e2 (commit) via 5f17ac8150906ce7aa05b28fdbd1a94cbe021ccc (commit) via 4b8ada818e21aae43b4f54f146ffa215fdb9213e (commit) from 0d1263af260d9bb7c4aeb29d1637da5fdc1a949e (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 0bd6fb3bc28b395d5af099221e2c0401d3be42e2 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 30 16:47:27 2008 -0500 Update -Ss and -Qs pactests to include groups This update causes query003 to fail before commit 4b8ada818e21aae43b4f54f146ffa215fdb9213e. Hopefully the issue doesn't crop up again but we might as well test for it. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5f17ac8150906ce7aa05b28fdbd1a94cbe021ccc Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 30 16:41:13 2008 -0500 Enable display of multiple groups in -Ss and -Qs output Not too complicated of a fix, but just adds some code to loop over the entire group list and space it out. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 4b8ada818e21aae43b4f54f146ffa215fdb9213e Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 30 16:14:44 2008 -0500 Fix segfault on -Qs usage This segfault creeped in as a result of commit bf867003. We were incorrectly assuming the group member of our package was a pmgrp_t list when in fact it is just a string list, which caused a segfault on any -Qs operation. Also slightly cleanup the -Ss code (which was originally correct unlike the -Qs code). Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: pactest/tests/query003.py | 1 + pactest/tests/sync1101.py | 1 + src/pacman/query.c | 14 +++++++++++--- src/pacman/sync.c | 16 +++++++++++----- 4 files changed, 24 insertions(+), 8 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-103-g0d1263a
by Dan McGee 30 Mar '08

30 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 0d1263af260d9bb7c4aeb29d1637da5fdc1a949e (commit) via 41c1295559bf4764c6b710cd14d300758c41a19a (commit) via d9b9e60d7d4943ec0395a66bd40d22089cfbee35 (commit) via 3fe43ffa04efd9937205938ef74d9dbba1a7aa42 (commit) via 562442633a9dd8026d914d785f15de2d0a95fdef (commit) from d140b440a86cc55bec6086e8d4a4d2606ebb6d1e (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 0d1263af260d9bb7c4aeb29d1637da5fdc1a949e Merge: 41c1295559bf4764c6b710cd14d300758c41a19a d9b9e60d7d4943ec0395a66bd40d22089cfbee35 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 30 13:42:24 2008 -0500 Merge branch 'maint' commit 41c1295559bf4764c6b710cd14d300758c41a19a Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 30 13:41:19 2008 -0500 doc/pacman.8: fix manpage typo Fix a misspelling and make a clarification while we are at it. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: doc/pacman.8.txt | 5 +++-- doc/pacman.conf.5.txt | 2 +- lib/libalpm/add.c | 4 ++-- lib/libalpm/remove.c | 8 ++++---- 4 files changed, 10 insertions(+), 9 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-16-gd9b9e60
by Dan McGee 30 Mar '08

30 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 d9b9e60d7d4943ec0395a66bd40d22089cfbee35 (commit) from 3fe43ffa04efd9937205938ef74d9dbba1a7aa42 (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: doc/pacman.conf.5.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Pacman maint release, possible translation updates (3.1.4)
by Dan McGee 30 Mar '08

30 Mar '08

A maint release is upcoming, mainly due to the following bug Xavier found and fixed: http://projects.archlinux.org/git/?p=pacman.git;a=commitdiff;h=3fe43ffa04ef… In addition, there are a few other changes of note, as you can see in the shortlog I've attached. With this said, any translators that wish to make any updates should try to get these to me ASAP. The PO files are unchanged from last time and are still available here (http://code.toofishes.net/pacman/po_files/) Of course, if you see your update below, it will already be included in the next release. Any questions, feel free to reply to this thread. Also, if you have a translation update coming but can't get it right away, let me know so I don't release before it comes in like last time. Thanks! -Dan $ git shortlog v3.1.3..maint | cat Chantry Xavier (7): rename vimproject to vimprojects and update it. src/pacman/pacman.c : split cleanup function. Use sigaction instead of signal. Clarify the NoUpgrade and NoExtract behavior. PKGBUILD.vim: improve invalid arch/license detection. PKGBUILD.vim: add keepend keyword for sha1/md5 fields Duplicate the result of archive_entry_pathname. Dan McGee (3): strsplit(): memleak fix memleak fix: ensure backup fname isn't lost if unused Fix manpage typo Nagy Gabor (3): Remove a bogus comment from libalpm/remove.c Show options in pacman.conf (commented out) Use pkgcache instead of db_scan in remove.c Sergey Tereschenko (1): Updates to Russian translation 甘露(Lu.Gan) (2): po/zh_CN.po: Chinese Simplified translation update Updates to Simplified Chinese translation

1 0

[pacman-dev] [PATCH] Add an archive_fgets() function
by Dan McGee 29 Mar '08

29 Mar '08

This crude function allows reading from an archive on a line-by-line basis similar to the familiar fgets() call on a FILE stream. This is the first step in being able to read DB entries straight from an archive. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- lib/libalpm/util.c | 29 +++++++++++++++++++++++++++++ lib/libalpm/util.h | 2 ++ 2 files changed, 31 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c index 806f601..92a0a26 100644 --- a/lib/libalpm/util.c +++ b/lib/libalpm/util.c @@ -673,4 +673,33 @@ int _alpm_test_md5sum(const char *filepath, const char *md5sum) return(ret); } +char *_alpm_archive_fgets(char *line, size_t size, struct archive *a) +{ + /* for now, just read one char at a time until we get to a + * '\n' char. we can optimize this later with an internal + * buffer. */ + /* leave room for zero terminator */ + int want = size - 1; + int loop; + + for(loop = 0; loop < want; loop++) { + int ret = archive_read_data(a, line + loop, 1); + /* special check for first read- if null, return null, + * this indicates EOF */ + if(loop == 0 && (ret <= 0 || line[loop] == '\0')) { + return(NULL); + } + /* check if read value was null or newline */ + if(ret <= 0 || line[loop] == '\0' || line[loop] == '\n') { + want = loop + 1; + break; + } + } + + /* always null terminate the buffer */ + line[want] = '\0'; + + return(line); +} + /* vim: set ts=2 sw=2 noet: */ diff --git a/lib/libalpm/util.h b/lib/libalpm/util.h index 6849fa1..0bf122c 100644 --- a/lib/libalpm/util.h +++ b/lib/libalpm/util.h @@ -30,6 +30,7 @@ #include <stdarg.h> #include <time.h> #include <sys/stat.h> /* struct stat */ +#include <archive.h> /* struct archive */ #ifdef ENABLE_NLS #include <libintl.h> /* here so it doesn't need to be included elsewhere */ @@ -66,6 +67,7 @@ char *_alpm_filecache_find(const char *filename); const char *_alpm_filecache_setup(void); int _alpm_lstat(const char *path, struct stat *buf); int _alpm_test_md5sum(const char *filepath, const char *md5sum); +char *_alpm_archive_fgets(char *line, size_t size, struct archive *a); #ifndef HAVE_STRVERSCMP int strverscmp(const char *, const char *); -- 1.5.4.4

6 9

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-15-g3fe43ff
by Dan McGee 29 Mar '08

29 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 3fe43ffa04efd9937205938ef74d9dbba1a7aa42 (commit) via 562442633a9dd8026d914d785f15de2d0a95fdef (commit) from 1086950c82ab649ffc36a00cd8d343da376252fe (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 3fe43ffa04efd9937205938ef74d9dbba1a7aa42 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Fri Mar 28 23:58:33 2008 +0100 Duplicate the result of archive_entry_pathname. After the libarchive upgrade from 2.4.12 to 2.4.14, our usage of archive_entry_pathname became dangerous. We were using the result of that function even after calls to archive_entry_set_pathname. With 2.4.14, the entryname becomes wrong after these calls, and so all the future use of entryname are bogus. entryname is used quite a lot for logging, so that's not so bad. But it's also used for the backup handling, so that's not very cool. For example, reinstalling a package with backup entries will erase all the md5 entries from the DB, because they won't be found back. entryname is now a static string so that we can easily keep the result of archive_entry_pathname. Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> [Dan: fixed version numbers in commit message] Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 562442633a9dd8026d914d785f15de2d0a95fdef Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Fri Mar 28 17:08:48 2008 +0100 Use pkgcache instead of db_scan in remove.c This should be a notable speed-up (apart from kernel cache). Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/add.c | 4 ++-- lib/libalpm/remove.c | 8 ++++---- 2 files changed, 6 insertions(+), 6 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] March 87 % Off!
by pacman-dev＠archlinux.org 29 Mar '08

29 Mar '08

1 0

[pacman-dev] Libalpm direction and usage by others
by Dan McGee 28 Mar '08

28 Mar '08

On Thu, Mar 27, 2008 at 10:42 AM, Aaron Griffin <aaronmgriffin(a)gmail.com> wrote: > On Thu, Mar 27, 2008 at 9:16 AM, Xavier <shiningxc(a)gmail.com> wrote: > > Raymano Garibaldi wrote: > > > > > > You can not expect people to use an API that has no clear > > > documentation and no stable interface that they can count on. And you > > > can not expect a developer to try to figure out an API by scanning > > > mailing lists, at least not this one. If it takes anyone longer to > > > figure out an API than write their own software, well guess what > > > they're going to do. > > > > > > > Then why don't they write an API with a clear documentation and a stable > > interface so that everyone could reuse it ? :) > > Or, better yet, document the API, or help us document it? It is clear to us on the list that no one has really latched on to using libalpm. To be honest, I don't blame anyone for this, as the interface seems to have been drawn at a bad level, and calling things like alpm_trans_commit() after 6 other functions and setting flags right just isn't intuitive. So, what does this lead us to? 1. Document the existing interface better. Although it isn't perfect, we aren't going to get frontend clients without documentation. As all of us working on the one client that does use libalpm (pacman) have clearly not felt a need for further documentation, this is really going to have to be spearheaded by someone outside of our current "normal" developers. Anyone want to step up? 2. Frontend developers need to speak up and get ideas on this list. I constantly see rhetoric like the above, where people say the current API is not very good, but they have not done a damn thing to change it. We can't read minds here, and we also aren't going to just change things on our own. So speak up people! If we get some good discussion going, we could really make changes to the API to make it usable. 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking "but that would be a step backwards!". Would it? I can tell you this- the pacman 2.9.8 codebase was about half the size of the current monster, and we have a lot of crazy design issues going on. Instead of trying to write a pacman library, why not just implement a friendly frontend, command-line interface, which is a bit more Unix-y? For example, monotone has its "automate" command (I haven't looked at this in some time, so let me know if I am wrong) that is designed to be used by other clients as machine-parseable. git is based around this concept as well- look at all the low level tools like rev-parse, etc. 4. Switch to something like python. I'm resistant to this idea. Although I think scripting languages like this have great benefits, I don't think pacman needs most of them. Having a package manager that always works is important to me, and part of me just thinks a low-level compiled language is the right thing for a system tool. Of the four options above, I have been pushing 1 and/or 2 for a long time. However, I am starting to lean toward option 3. I'd love to hear your thoughts on this. -Dan

7 9

[pacman-dev] [PATCH] Use pkgcache instead of db_scan in remove.c
by Nagy Gabor 28 Mar '08

28 Mar '08

From 51abd287f9c40499f6985c3266441780a04c298c Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Fri, 28 Mar 2008 17:06:49 +0100 Subject: [PATCH] Use pkgcache instead of db_scan in remove.c This should be a notable speed-up (apart from kernel cache). Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/deps.c | 2 +- lib/libalpm/remove.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 1eebca3..2d92179 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -506,7 +506,7 @@ void _alpm_recursedeps(pmdb_t *db, alpm_list_t *targs, int include_explicit) && can_remove_package(db, deppkg, targs, include_explicit)) { _alpm_log(PM_LOG_DEBUG, "adding '%s' to the targets\n", alpm_pkg_get_name(deppkg)); - /* add it to the target list */ + /* add it to the target list */ targs = alpm_list_add(targs, _alpm_pkg_dup(deppkg)); } } diff --git a/lib/libalpm/remove.c b/lib/libalpm/remove.c index dfdcabe..8d83294 100644 --- a/lib/libalpm/remove.c +++ b/lib/libalpm/remove.c @@ -61,7 +61,7 @@ int _alpm_remove_loadtarget(pmtrans_t *trans, pmdb_t *db, char *name) RET_ERR(PM_ERR_TRANS_DUP_TARGET, -1); } - if((info = _alpm_db_scan(db, name)) == NULL) { + if((info = _alpm_db_get_pkgfromcache(db, name)) == NULL) { _alpm_log(PM_LOG_DEBUG, "could not find %s in database\n", name); RET_ERR(PM_ERR_PKG_NOT_FOUND, -1); } @@ -77,7 +77,7 @@ int _alpm_remove_loadtarget(pmtrans_t *trans, pmdb_t *db, char *name) } _alpm_log(PM_LOG_DEBUG, "adding %s in the targets list\n", info->name); - trans->packages = alpm_list_add(trans->packages, info); + trans->packages = alpm_list_add(trans->packages, _alpm_pkg_dup(info)); return(0); } @@ -107,12 +107,12 @@ int _alpm_remove_prepare(pmtrans_t *trans, pmdb_t *db, alpm_list_t **data) alpm_list_t *i; for(i = lp; i; i = i->next) { pmdepmissing_t *miss = (pmdepmissing_t *)i->data; - pmpkg_t *info = _alpm_db_scan(db, miss->target); + pmpkg_t *info = _alpm_db_get_pkgfromcache(db, miss->target); if(info) { if(!_alpm_pkg_find(alpm_pkg_get_name(info), trans->packages)) { _alpm_log(PM_LOG_DEBUG, "pulling %s in the targets list\n", alpm_pkg_get_name(info)); - trans->packages = alpm_list_add(trans->packages, info); + trans->packages = alpm_list_add(trans->packages, _alpm_pkg_dup(info)); } } else { _alpm_log(PM_LOG_ERROR, _("could not find %s in database -- skipping\n"), -- 1.5.3.8

1 1

[pacman-dev] [PATCH] Keep pkgcaches and dbs in sync
by Nagy Gabor 28 Mar '08

28 Mar '08

From db6d957330d03f3c369001c0fb91e6dec8d5651d Mon Sep 17 00:00:00 2001 From: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Thu, 27 Mar 2008 18:55:52 +0100 Subject: [PATCH] Keep pkgcaches and dbs in sync Ref.: http://www.archlinux.org/pipermail/pacman-dev/2007-September/009429.html http://bugs.frugalware.org/index.php?do=details&task_id=2533 This patch based on the work of Vajna Miklos (vmiklos) from pacman-g2. It's time to fix this issue, since we have upcoming GUIs. Briefly, the problem is that pkgcache can become outdated. The trivial fix would be: reload pkgcache immediately after db lock. We follow a more sophisticated approach to minimize overhead: 1. Each dbs on HDD have a "fingerprint": .lastupdate (patch extends this to localdb too) 2. After pkgcache load this fingerprint is recorded to the new fingerprint field of pmdb_t 3. New _alpm_db_refrech_pkgcache was introduced to reload cache, if it outdated. (Note: fingerprint treats transaction atomic.) Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> --- lib/libalpm/cache.c | 17 +++++++++++++++++ lib/libalpm/cache.h | 1 + lib/libalpm/db.h | 1 + lib/libalpm/trans.c | 11 +++++++++++ 4 files changed, 30 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/cache.c b/lib/libalpm/cache.c index 7fa2405..8922dca 100644 --- a/lib/libalpm/cache.c +++ b/lib/libalpm/cache.c @@ -67,6 +67,7 @@ int _alpm_db_load_pkgcache(pmdb_t *db) } db->pkgcache = alpm_list_msort(db->pkgcache, count, _alpm_pkg_cmp); + db->fingerprint = _alpm_db_getlastupdate(db); return(0); } @@ -90,6 +91,22 @@ void _alpm_db_free_pkgcache(pmdb_t *db) } } +/* Reload pkgcache if it is outdated + */ +int _alpm_db_refresh_pkgcache(pmdb_t *db) { + ALPM_LOG_FUNC; + + if(db == NULL) { + return(-1); + } + + if(!db->pkgcache || (db->fingerprint != _alpm_db_getlastupdate(db))) { + return(_alpm_db_load_pkgcache(db)); + } + + return(0); +} + alpm_list_t *_alpm_db_get_pkgcache(pmdb_t *db) { ALPM_LOG_FUNC; diff --git a/lib/libalpm/cache.h b/lib/libalpm/cache.h index 915896e..4569b70 100644 --- a/lib/libalpm/cache.h +++ b/lib/libalpm/cache.h @@ -27,6 +27,7 @@ /* packages */ int _alpm_db_load_pkgcache(pmdb_t *db); void _alpm_db_free_pkgcache(pmdb_t *db); +int _alpm_db_refresh_pkgcache(pmdb_t *db); int _alpm_db_add_pkgincache(pmdb_t *db, pmpkg_t *pkg); int _alpm_db_remove_pkgfromcache(pmdb_t *db, pmpkg_t *pkg); alpm_list_t *_alpm_db_get_pkgcache(pmdb_t *db); diff --git a/lib/libalpm/db.h b/lib/libalpm/db.h index 8c8c9bd..cd362d5 100644 --- a/lib/libalpm/db.h +++ b/lib/libalpm/db.h @@ -45,6 +45,7 @@ struct __pmdb_t { alpm_list_t *pkgcache; alpm_list_t *grpcache; alpm_list_t *servers; + time_t fingerprint; /* of pkgcache */ }; /* db.c, database general calls */ diff --git a/lib/libalpm/trans.c b/lib/libalpm/trans.c index 3edbbac..f425147 100644 --- a/lib/libalpm/trans.c +++ b/lib/libalpm/trans.c @@ -65,6 +65,7 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, alpm_trans_cb_progress progress) { ALPM_LOG_FUNC; + alpm_list_t *i; /* Sanity checks */ ASSERT(handle != NULL, RET_ERR(PM_ERR_HANDLE_NULL, -1)); @@ -77,6 +78,12 @@ int SYMEXPORT alpm_trans_init(pmtranstype_t type, pmtransflag_t flags, RET_ERR(PM_ERR_HANDLE_LOCK, -1); } + /* ensure dbs and pkgcaches are in sync */ + _alpm_db_refresh_pkgcache(handle->db_local); + for(i = handle->dbs_sync; i; i = i->next) { + _alpm_db_refresh_pkgcache(i->data); + } + handle->trans = _alpm_trans_new(); if(handle->trans == NULL) { RET_ERR(PM_ERR_MEMORY, -1); @@ -203,6 +210,10 @@ int SYMEXPORT alpm_trans_release() _alpm_trans_free(trans); handle->trans = NULL; + time_t fingerprint = time(NULL); + _alpm_db_setlastupdate(handle->db_local, fingerprint); + handle->db_local->fingerprint = fingerprint; + /* unlock db */ if(handle->lckfd != -1) { close(handle->lckfd); -- 1.5.3.8

1 3

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-98-gd140b44
by Dan McGee 28 Mar '08

28 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 d140b440a86cc55bec6086e8d4a4d2606ebb6d1e (commit) via f8c737d3b6b28373a69d5979a4ba2e31b77baa62 (commit) via 1dfd841e40344ff401e0d9e8d61b55cb64b2681f (commit) from 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d (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 d140b440a86cc55bec6086e8d4a4d2606ebb6d1e Author: Dan McGee <dan(a)archlinux.org> Date: Wed Mar 26 21:26:43 2008 -0500 Read .PKGINFO directly from package file With the addition of the archive_fgets() function, we can now skip the temp file usage in pkg_load/parse_descfile that was not needed. This has a nice benefit of probably being both faster, reducing code, and getting rid of "expensive" file operations. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f8c737d3b6b28373a69d5979a4ba2e31b77baa62 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Mar 25 21:23:14 2008 -0500 Add an archive_fgets() function This crude function allows reading from an archive on a line-by-line basis similar to the familiar fgets() call on a FILE stream. This is the first step in being able to read DB entries straight from an archive. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 1dfd841e40344ff401e0d9e8d61b55cb64b2681f Author: Dan McGee <dan(a)archlinux.org> Date: Wed Mar 26 20:19:44 2008 -0500 Make db->treename a pointer I really don't think we need statically allocated strings here. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/db.c | 4 +- lib/libalpm/db.h | 2 +- lib/libalpm/package.c | 61 +++++++++---------------------------------------- lib/libalpm/util.c | 29 +++++++++++++++++++++++ lib/libalpm/util.h | 2 + 5 files changed, 45 insertions(+), 53 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

Ops, I re-read it badly, just ignore my last post, I'm a bit tired... Dario

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

sorry, I think alpm is totally shit was I don't think alpm is totally shit but I think you got that ^^ Dario

1 0

[pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

> > Well, I am not sure why you felt offended, Dan didn't mean it that way. > I'm not offended, I just feared that libalpm could disappear and all my efforts wasted. > What you did is indeed great, that would be the first real frontend > using libalpm. (well there is also gfpm using frugalware's libpacman, > but I don't think anyone really ported it to libalpm, at least it's not > uptodate). > Thanks a lot :) > But actually, that's the point, you are the only one, while there are > countless of others tools simply calling pacman, or parsing the stuff > themselves. > Exactly. This is the point. Experience teaches me one thing: people stick to habits. I think the only reason I developed Shaman this way is because I'm new to Arch, and alpm already existed. If Shaman previously used pacman and worked, I don't think I'd have taken the risk to port it to alpm. Or maybe, people still fear libalpm. Maybe they don't even know what it does, why it exists. Maybe they think it's a bit harder, well it is. But there is a huge difference. > Still, your project should give us a better idea about the quality and > usefulness of libalpm, and I hope that you will have concrete > suggestions for improving libalpm and making it more friendly to use :) That's why I showed you the link here. It was not a "oh, look, I'm so good", because I consider myself a really worse coder than the ones who develop pacman/alpm, and I'm speaking for real. I'm not talking about who can code better, I'm talking about ideas, and not coding. Sorry to say that, but Xavier, it was you who answered my mail. It was you who answered Lukas when he asked about alpm version. It is you that says that doors are open, and I really appreciate that. The point is that, even here, you're the only one. Because nobody else replied to that mail (or at least, replied to the point of that mail) but you. I don't pretend to be the solution of all the problems, and maybe some of my ideas are wrong, but developing Shaman helped me seeing a lot of flaws in alpm. A lot of unsafe behaviours. And this doesn't mean that I think alpm is totally shit. Do you think I'd have developed something upon pure shit? I'm not so masochist. Ok, sometimes I said it was, but it was frustration that made me speak. And I DO think that libalpm is worth the effort. Shaman is the living demostration that alpm works, that alpm is useful, both to developers and users, even if it has some design flaws. And I don't want it to die, because it doesn't have to. Alpm is more stable/efficient than apt/dpkg in my opinion, even if some bad choices in DB handling make it slower in searching and loading the database, but I've seen nothing handling package processing that fast, and that's the reason why I bet on Shaman, and I'd still make the same choice now. But I do believe that libalpm can be even faster. That something can be improved to make it even better. And that should be the question and the direction, being honest on ourself. And not listening to trolls who just say some banal/stupid stuff about SQLite and such, not saying "complicated and not worth it" when you don't even know what that thing could mean. I hope that was a bit clearer. Cheers Dario

1 0

Re: [pacman-dev] Libalpm direction and usage by others
by Dario Freddi 27 Mar '08

27 Mar '08

> > It is clear to us on the list that no one has really latched on to > using libalpm. Don't agree > To be honest, I don't blame anyone for this, as the > interface seems to have been drawn at a bad level, and calling things > like alpm_trans_commit() after 6 other functions and setting flags > right just isn't intuitive. > Agreed. > So, what does this lead us to? > 1. Document the existing interface better. Although it isn't perfect, > we aren't going to get frontend clients without documentation. As all > of us working on the one client that does use libalpm (pacman) have > clearly not felt a need for further documentation, this is really > going to have to be spearheaded by someone outside of our current > "normal" developers. Anyone want to step up? > Stop on that. When I started my work, I had only this (http://code.toofishes.net/pacman/doc/index.html) and the code. You know what? That was enough, and I didn't EVER complain about it. A competent programmer knows that, even if he had the best documentation around, sooner or later he will have to see the code to understand how things **really** work out. Sure, an improvement could be good, but don't forget that something is already out there. > 2. Frontend developers need to speak up and get ideas on this list. I > constantly see rhetoric like the above, where people say the current > API is not very good, but they have not done a damn thing to change > it. We can't read minds here, and we also aren't going to just change > things on our own. So speak up people! If we get some good discussion > going, we could really make changes to the API to make it usable. > I once sent a mail, I proposed some ideas, I got one (1) answer, and... what? I proposed to abstract the backend, some real things, I'm writing a whole paper on that, I'm ready to show you something REAL, some real ideas, some people who really want to do that but... where is the list? Why just shining answered to my mail? Why didn't anybody else step up and said: "Ok good" or "No, sucks". You wanna see some code? Some efforts? Is that one enough? http://shaman.iskrembilen.com/trac.cgi/wiki I wrapped libalpm around a C++ class and guess what? It works. It still has issues, but shaman works, and while I'm writing, a lot of people are using it, even if I still haven't put it on Arch bbs, since I want it to reach a real beta stage (where beta means usable, feature full, with some minor stuff, something we've almost achieved). Will somebody listen to that now? Will somebody say that alpm, library or not, needs improvements and not in the code, in the basic ideas around it? Will somebody finally admit that it's time to hear other voices? In my opinion, simplicity is also making life easier. Having a choice between db frontends is simple, since everyone can write its backend, and it gives the user freedom to use whatever it wants. > 3. Scrap the whole libalpm/split idea. Whoa! I know you are thinking > "but that would be a step backwards!". Would it? I can tell you this- > the pacman 2.9.8 codebase was about half the size of the current > monster, and we have a lot of crazy design issues going on. Instead of > trying to write a pacman library, why not just implement a friendly > frontend, command-line interface, which is a bit more Unix-y? For > example, monotone has its "automate" command (I haven't looked at this > in some time, so let me know if I am wrong) that is designed to be > used by other clients as machine-parseable. git is based around this > concept as well- look at all the low level tools like rev-parse, etc. > 4. Switch to something like python. I'm resistant to this idea. > Although I think scripting languages like this have great benefits, I > don't think pacman needs most of them. Having a package manager that > always works is important to me, and part of me just thinks a > low-level compiled language is the right thing for a system tool. > Python or not, don't even think on that. First of all, all our efforts into shaman would be a waste. Secondly, you close every door through a different frontend than pacman, and I don't really think this is really the Arch way. > Of the four options above, I have been pushing 1 and/or 2 for a long > time. However, I am starting to lean toward option 3. I'd love to hear > your thoughts on this. > This is my thought. Out there, a lot of people have great ideas about pacman/alpm, but nobody here ever seemed to have listened to them. You asked for some code, I brought you Shaman. I'm ready to get up with some well documented ideas, but I don't know if there is the right attitude to accept other point of views. And I'm not talking about the SQLite stuff - I hate SQLite, and it sucks for a package manager. But honestly... would you give alpm the fault for all those void*s, for all that useless package structs, and whatever else? There is someone who latched over libalpm, and it's me. I believed in it, even a lot of stuff was wrong, and the result is Shaman. You can say you don't like it, ok, that's fine. What you can't say is that it is a real step forward compared to gtkpacman & friends, that used pacman instead (I'm not saying they're bad, I'm just showing the difference in wrapping pacman and libalpm, gtkpacman still remains a piece of software IMHO) > -Dan > Didn't mean to offend anyone, sorry if I did. Cheers Dario

2 1

[pacman-dev] PacTrac was: Re: [arch-general] [arch-dev-public] ArchISO FTP Installer - Testers Needed
by Roman Kyrylych 27 Mar '08

27 Mar '08

2008/3/27, Christos Nouskas <nouskas(a)gmail.com>: > Damir Perisa wrote: > > i have a no-optical-drive laptop (non-macs are not able to boot from > > firewire cdroms) and usually i prepare a image to put on a > > memory-stick to boot from [1]. since this setting (no cdrom) are > > getting more common and having a live-linux-system on a usb-key is > > getting interesting i'm wondering if we should provide also a > > partition image[2] for such use? > > > I've been using FaunOS (http://www.faunos.com/) for a couple of months > now, and my opinion can only be described as excellent. It's a live > archlinux system focused on booting from detachable usb media, fits in a > 1GB stick, does a wonderful job in hardware detection (I tested it in 3 > different machines), saves all changes back to the usb stick, suspends to > usb and it's FAAAAAST! Wherever I can't take my arch-laptop, I take my > usb stick! Hm, it has an interesting frontend to pacman - PacTrac. I especially like the dependency tree: http://www.faunos.com/images/ver-0.5.4-stable/pactrac-install.png -- Roman Kyrylych (Роман Кирилич)

7 10

Re: [pacman-dev] [arch-general] lzma compression tests
by Dan McGee 25 Mar '08

25 Mar '08

CCing to pacman-dev. On Mon, Mar 24, 2008 at 3:25 PM, Jan de Groot <jan(a)jgc.homeip.net> wrote: > > On Mon, 2008-03-24 at 14:43 -0500, Dan McGee wrote: > > On Mon, Mar 24, 2008 at 2:24 PM, Mark Constable <markc(a)renta.net> wrote: > > > FWIW, possibly worth considering adding lzma to pacman... > > > > > > http://www.kdedevelopers.org/node/3326 > > > > > > --markc > > > > Interesting. You may want ot take this to the pacman-dev ML. A good > > "real-world" look might be grabbing the openoffice package and > > uncompressing it to a folder, and then run the following tests: > > > > bsdtar czf package (gzip) > > bsdtar cjf package (bzip2) > > <lzma creation of package> > > > > and then the similar unzip costs, along with the size of the original > > folder structure (unzipped package) vs. their zipped counterparts. > > > > -Dan > > > > I tested with OpenOffice.org, here are the results. Note that I had to > use a weird construction to compress lzma files, as tar has no native > support yet (1.19.90 has official lzma support I read on some debian > mailinglist). > > Compression times take a huge increase in time, but in case of > openoffice, I think 30 seconds extra compression time will save on much > more upload time, as the resulting package would be 20MB smaller. > For the end user, it depends on their connection. Most users will have > <10Mb/s connections and will see a positive change in installation > speed: 10 seconds extra for extraction, 20 seconds less for downloading > the package. > > [jan@server ~]$ time bsdtar czf oo.tar.gz oo/ > real 0m24.244s > user 0m23.882s > sys 0m0.360s > > [jan@server ~]$ time bsdtar cjf oo.tar.bz2 oo/ > real 0m55.812s > user 0m55.310s > sys 0m0.377s > > [jan@server ~]$ time tar c oo | lzma -2 > oo.tar.lzma > real 0m55.070s > user 0m54.583s > sys 0m0.740s > > [jan@server ~]$ time tar c oo | lzma -1 > oo.tar.lzma1 > real 0m38.995s > user 0m38.737s > sys 0m0.503s > > [jan@server ~]$ du -h oo.tar.* > 108M oo.tar.bz2 > 115M oo.tar.gz > 95M oo.tar.lzma > 101M oo.tar.lzma1 > > [jan@server u]$ time tar zxf ../oo.tar.gz > real 0m3.570s > user 0m3.383s > sys 0m0.967s > > [jan@server u]$ time tar jxf ../oo.tar.bz2 > real 0m19.431s > user 0m17.826s > sys 0m1.367s > > [jan@server u]$ time tar --use-compress-program=lzma -xf ../oo.tar.lzma > real 0m13.211s > user 0m12.306s > sys 0m1.117s > (the lzma1 archive gives equal timings) Did you try with bsdtar on the extraction as well? That may make a difference over (gnu)tar. Should be: time bsdtar xf ../oo.tar.gz time bsdtar xf ../oo.tar.bz2 time bsdtar --use-compress-program=lzma -xf ../oo.tar.lzma -Dan

3 2

[pacman-dev] bug during package upgrade?
by Roman Kyrylych 24 Mar '08

24 Mar '08

Hi! Here's Tobias' pacman.log. Notice that klibc-kbd is not installed at all, though the newest mkinitcpio depends on it. The line [2008-03-21 19:57] installed klibc-kbd (1.15.20080312-4) at the bottom is from manual installation. ---------- Forwarded message ---------- From: Tobias Powalowski <t.powa(a)gmx.de> Date: 22 бер. 2008 00:14 Subject: big upgrade To: Roman Kyrylych <roman.kyrylych(a)gmail.com> -- Roman Kyrylych (Роман Кирилич)

4 9

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.1.3-13-g1086950
by Dan McGee 23 Mar '08

23 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 1086950c82ab649ffc36a00cd8d343da376252fe (commit) via 7995a25d0ed75968df72fcf65d231508417ec060 (commit) from 7d451b6e6bc3926589a77e6a2d191e4f158d3980 (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: lib/libalpm/add.c | 1 + lib/libalpm/backup.c | 3 +++ src/pacman/util.c | 2 +- 3 files changed, 5 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.1.3-95-g5f1ccdb
by Dan McGee 23 Mar '08

23 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 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d (commit) via d1ea16dfd0d497aff72d7a315890971e7f070786 (commit) via 6104f2e1fb872c32d3e6ed1823729592fc6245b9 (commit) via 1086950c82ab649ffc36a00cd8d343da376252fe (commit) via 7995a25d0ed75968df72fcf65d231508417ec060 (commit) via bf8670036907b3ede18d37b7a3f0f7e14542a5ac (commit) via 90a48c771d727e3bd231eeb1611dfcbecb88490c (commit) via f7f43dbb48add85c3c3e42696c4d3bae4591a7d6 (commit) via 3d10d460dff4c1321b40fa509c4ff9be93db0ca3 (commit) via 5af076f09f67bb3abd80a28fa3f33437f08b18bc (commit) from 2f8fb80ee631ef866c3bd8cb5fab09a7360ca8d2 (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 5f1ccdbc27e3b4b92f9b65379db17a4d6523975d Merge: d1ea16dfd0d497aff72d7a315890971e7f070786 1086950c82ab649ffc36a00cd8d343da376252fe Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 16:58:53 2008 -0500 Merge branch 'maint' commit d1ea16dfd0d497aff72d7a315890971e7f070786 Author: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Date: Tue Mar 11 16:40:27 2008 +0100 Avoid duplicated target names. This patch should avoid duplicated target names in the backend. 1. sync_loadtarget will return with PM_ERR_TRANS_DUP_TARGET when trying to add a duplicated target 2. sysupgrade never pulls duplicated targets 3. resolvedeps won't pull duplicated targets anymore A pulled list was introduced in sync_prepare to improve the pmsyncpkg_t<->pmpkg_t list conversion by making it more direct. Also replace sync1005 and sync1006 by the sync1008 pactest, which is similar but more interesting (the provisions are dependencies instead of explicit targets). sync1005 didn't work as expected anyway. It was expecting that pacman failed, and pacman indeed failed, but not for the good reason. It didn't fail during the preparation step because of conflicting targets, but during the commit step, because of a md5 error... And sync1006 didn't pass and was not really worth fixing. We have already enough failing pactests more important than these two. sync1008 pass with this patch. Signed-off-by: Nagy Gabor <ngaba(a)bibl.u-szeged.hu> Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> commit 6104f2e1fb872c32d3e6ed1823729592fc6245b9 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 15:35:22 2008 -0500 memleak fix: ensure we free result of get_destfile() In the file:// download case, we didn't free the return from get_destfile() after we were done with it. Fix it. (Found with xfercommand001.py) Signed-off-by: Dan McGee <dan(a)archlinux.org> commit bf8670036907b3ede18d37b7a3f0f7e14542a5ac Author: Dan McGee <dan(a)archlinux.org> Date: Sat Jan 12 01:13:52 2008 -0600 Switch pmgrp_t to dynamic allocation, general group cleanup Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 90a48c771d727e3bd231eeb1611dfcbecb88490c Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 14:25:38 2008 -0500 Add -q (quiet) option to valgrind call in pactest This gets rid of a lot of the unnecessary verbosity in the --valgrind output when running all the tests. It should also make diff-ing output between test runs a lot easier. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f7f43dbb48add85c3c3e42696c4d3bae4591a7d6 Author: Dan McGee <dan(a)archlinux.org> Date: Sun Mar 23 14:08:31 2008 -0500 Update database mtime after it has been extracted This will reduce the need for running an -Syy if the DB was only half-extracted, as the mtime won't get updated until the new database is completely in place. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3d10d460dff4c1321b40fa509c4ff9be93db0ca3 Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sat Feb 16 16:01:13 2008 +0100 Add new CleanMethod option. As it was already mentioned several times, the new -Sc behavior in 3.1 is great, but only when the package cache is not shared. This option has two possible values : KeepInstalled and KeepCurrent With KeepCurrent, -Sc will clean packages that are no longer available in any sync db, rather than packages that are no longer in the local db. The resulting behavior should be better for shared cache. Ref : http://www.archlinux.org/pipermail/pacman-dev/2008-February/011140.html Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 5af076f09f67bb3abd80a28fa3f33437f08b18bc Author: Chantry Xavier <shiningxc(a)gmail.com> Date: Sat Mar 15 21:10:54 2008 +0100 Kill the dependsonly option. From the man page : "This is pretty useless and we're not sure why it even exists." Signed-off-by: Chantry Xavier <shiningxc(a)gmail.com> ----------------------------------------------------------------------- Summary of changes: contrib/bash_completion | 1 - contrib/zsh_completion | 1 - doc/pacman.8.txt | 7 +- doc/pacman.conf.5.txt | 9 +++ lib/libalpm/add.c | 1 + lib/libalpm/alpm.h | 4 +- lib/libalpm/backup.c | 3 + lib/libalpm/cache.c | 50 ++++++-------- lib/libalpm/db.c | 20 +++-- lib/libalpm/deps.c | 6 +- lib/libalpm/dload.c | 11 ++-- lib/libalpm/group.c | 9 ++- lib/libalpm/group.h | 11 ++-- lib/libalpm/sync.c | 57 +++++++-------- pactest/pmtest.py | 2 +- pactest/tests/sync1001.py | 18 ----- pactest/tests/sync1002.py | 19 ----- pactest/tests/sync1006.py | 14 ---- pactest/tests/{sync1005.py => sync1008.py} | 11 ++- src/pacman/conf.h | 14 +++- src/pacman/pacman.c | 13 +++- src/pacman/query.c | 28 ++++---- src/pacman/sync.c | 106 ++++++++++++++++++++------- src/pacman/util.c | 2 +- 24 files changed, 221 insertions(+), 196 deletions(-) delete mode 100644 pactest/tests/sync1001.py delete mode 100644 pactest/tests/sync1002.py delete mode 100644 pactest/tests/sync1006.py rename pactest/tests/{sync1005.py => sync1008.py} (54%) hooks/post-receive -- The official pacman repository

1 0