Re: [pacman-dev] [PATCH 2/6] Add helper methods for setting directory options

2011-06-03 Thread Allan McRae
On 04/06/11 08:40, Dan McGee wrote: This keeps duplicate code to a minimum and also addresses the issue where calling set_cachedirs() didn't canonicalize the passed-in paths. This will come in more handy as we refactor some of these option setters away. Signed-off-by: Dan McGee --- int SY

Re: [pacman-dev] [PATCH 5/6] Update utilities for new initialize/release methods

2011-06-03 Thread Allan McRae
On 04/06/11 08:41, Dan McGee wrote: Signed-off-by: Dan McGee --- src/util/cleanupdelta.c | 14 -- src/util/pactree.c | 23 +++ src/util/testdb.c | 17 - src/util/testpkg.c | 11 +++ 4 files changed, 30 insertion

[pacman-dev] [PATCH 4/6] New signatures for alpm initialize and release

2011-06-03 Thread Dan McGee
These new method signatures return and take handle objects to operate on so we can move away from the idea of one global handle in the API. There is also another important change and that deals with the setting of root and dbpaths. These are now done at initialization time instead of using setter m

[pacman-dev] [PATCH 6/6] Revamp pacman setup code to handle new alpm initialize routine

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- src/pacman/conf.c | 205 --- src/pacman/conf.h | 16 - src/pacman/pacman.c | 52 +++-- 3 files changed, 140 insertions(+), 133 deletions(-) diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 3

[pacman-dev] [PATCH 5/6] Update utilities for new initialize/release methods

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- src/util/cleanupdelta.c | 14 -- src/util/pactree.c | 23 +++ src/util/testdb.c | 17 - src/util/testpkg.c | 11 +++ 4 files changed, 30 insertions(+), 35 deletions(-) diff --git a/src/ut

[pacman-dev] [PATCH 3/6] Be consistent with memory treatment for plural option setters

2011-06-03 Thread Dan McGee
In all cases we should duplicate the passed-in list so the caller is free to do with it as it pleases. Signed-off-by: Dan McGee --- lib/libalpm/handle.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c index 0b0db

[pacman-dev] [PATCH 2/6] Add helper methods for setting directory options

2011-06-03 Thread Dan McGee
This keeps duplicate code to a minimum and also addresses the issue where calling set_cachedirs() didn't canonicalize the passed-in paths. This will come in more handy as we refactor some of these option setters away. Signed-off-by: Dan McGee --- lib/libalpm/alpm.c |1 + lib/libalpm/deps.c

[pacman-dev] [PATCH 1/6] Use standard errno codes in return from _alpm_archive_fgets

2011-06-03 Thread Dan McGee
This allows us to not require the context (e.g. handle) when calling this function. Also beef up the checks in the two callers of this function to bail if the last return code is not ARCHIVE_EOF, which is the expected value. This requires a change to one of the pactest return codes and the overall

Re: [pacman-dev] Does anyone use ALPM_LOG_FUNC?

2011-06-03 Thread Allan McRae
On 04/06/11 03:45, Dave Reisner wrote: On Fri, Jun 03, 2011 at 10:12:32AM -0500, Dan McGee wrote: It isn't even enabled in non-debug builds, so this seems like a not-so-useful feature as a debugger and/or a few printf() calls will help you do anything this can, and will be a lot less crazy. If t

Re: [pacman-dev] [PATCH 02/10] Remove unnecessary handle != NULL asserts

2011-06-03 Thread Dan McGee
On Fri, Jun 3, 2011 at 1:27 PM, Rémy Oudompheng wrote: > Signing off all patches 2 -> 10, it will give me some more work to > port pyalpm :) The eventual outcome is definitely some API changes, but I think it really moves it int he right direction. Unfortuantely, nearly every frontend will need t

Re: [pacman-dev] [PATCH 02/10] Remove unnecessary handle != NULL asserts

2011-06-03 Thread Rémy Oudompheng
Signing off all patches 2 -> 10, it will give me some more work to port pyalpm :) -- Rémy.

[pacman-dev] [PATCH 10/10] Remove global handle dependencies from sync/upgrade paths

2011-06-03 Thread Dan McGee
This kills a lot more global handle business off. sync.c still requires the handle declaration for one reference that can't be changed yet; it will be removed in a future patch which isolates all of the necesary API changes. Signed-off-by: Dan McGee --- lib/libalpm/add.c | 53

[pacman-dev] [PATCH 09/10] Remove global handle from remove.c

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- lib/libalpm/add.c|2 +- lib/libalpm/remove.c | 51 + lib/libalpm/remove.h |7 +++-- lib/libalpm/sync.c |2 +- lib/libalpm/trans.c |4 +- 5 files changed, 30 insertions(+), 36 deletions(-) diff -

[pacman-dev] [PATCH 08/10] Remove global handle from some package and db code

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- lib/libalpm/alpm.c |2 +- lib/libalpm/be_local.c | 20 ++-- lib/libalpm/be_sync.c | 10 +++--- lib/libalpm/db.c | 11 +-- lib/libalpm/db.h |4 ++-- lib/libalpm/package.c | 11 --- 6 files changed, 1

[pacman-dev] [PATCH 07/10] Remove global handle from diskspace.c

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- lib/libalpm/diskspace.c | 22 ++ lib/libalpm/diskspace.h |2 +- lib/libalpm/sync.c |2 +- 3 files changed, 12 insertions(+), 14 deletions(-) diff --git a/lib/libalpm/diskspace.c b/lib/libalpm/diskspace.c index f864518..c6c0b98 10064

[pacman-dev] [PATCH 06/10] Remove global handle from util.c

2011-06-03 Thread Dan McGee
Signed-off-by: Dan McGee --- lib/libalpm/add.c| 18 +- lib/libalpm/remove.c | 10 +- lib/libalpm/trans.c | 13 ++--- lib/libalpm/trans.h |5 ++--- lib/libalpm/util.c | 23 +++ lib/libalpm/util.h |5 +++-- 6 files change

[pacman-dev] [PATCH 05/10] Push down extern handle variable to files that need it

2011-06-03 Thread Dan McGee
This will make the patching process less invasive as we start to remove this variable from all source files. Signed-off-by: Dan McGee --- lib/libalpm/add.c|3 +++ lib/libalpm/alpm.c |1 + lib/libalpm/be_local.c |2 ++ lib/libalpm/be_package.c |3 +++ lib/libalpm/b

[pacman-dev] [PATCH 04/10] Add handle attribute to pmpkg_t struct

2011-06-03 Thread Dan McGee
Similar to what we just did for the database; this will make it easy to always know what handle a given package originated from. Signed-off-by: Dan McGee --- lib/libalpm/be_local.c |1 + lib/libalpm/be_package.c |2 ++ lib/libalpm/be_sync.c|3 ++- lib/libalpm/package.c|

[pacman-dev] [PATCH 03/10] Add handle attribute to pmdb_t struct

2011-06-03 Thread Dan McGee
This is the first step in a long process to remove our dependence on the global handle variable we currently share in libalpm, with the goal to make things a bit more thread-safe and re-entrant. Signed-off-by: Dan McGee --- lib/libalpm/alpm.h |1 + lib/libalpm/be_local.c |1 + lib/li

[pacman-dev] [PATCH 02/10] Remove unnecessary handle != NULL asserts

2011-06-03 Thread Dan McGee
These are simple accessor functions for a struct; the handle never even comes into play when calling these functions. Signed-off-by: Dan McGee --- lib/libalpm/conflict.c |7 --- lib/libalpm/db.c |8 2 files changed, 0 insertions(+), 15 deletions(-) diff --git a/lib/li

[pacman-dev] [PATCH 01/10] Remove ALPM_LOG_FUNC macro

2011-06-03 Thread Dan McGee
The usefulness of this is rather limited due to it not being compiled into production builds. When you do choose to see the output, it is often overwhelming and not helpful. The best bet is to use a debugger and/or well-placed fprintf() statements. Signed-off-by: Dan McGee --- lib/libalpm/add.c

Re: [pacman-dev] Does anyone use ALPM_LOG_FUNC?

2011-06-03 Thread Dave Reisner
On Fri, Jun 03, 2011 at 10:12:32AM -0500, Dan McGee wrote: > It isn't even enabled in non-debug builds, so this seems like a > not-so-useful feature as a debugger and/or a few printf() calls will > help you do anything this can, and will be a lot less crazy. If there > are no objections I'd like to

Re: [pacman-dev] Does anyone use ALPM_LOG_FUNC?

2011-06-03 Thread Yaro Kasear
On Friday, June 03, 2011 10:12:32 Dan McGee wrote: > It isn't even enabled in non-debug builds, so this seems like a > not-so-useful feature as a debugger and/or a few printf() calls will > help you do anything this can, and will be a lot less crazy. If there > are no objections I'd like to kill it

[pacman-dev] Does anyone use ALPM_LOG_FUNC?

2011-06-03 Thread Dan McGee
It isn't even enabled in non-debug builds, so this seems like a not-so-useful feature as a debugger and/or a few printf() calls will help you do anything this can, and will be a lot less crazy. If there are no objections I'd like to kill it. The motivation for this change will be shared soon as wel