- Pacman-dev - lists.archlinux.org

[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