[pacman-dev] [PATCH 1/2] Make sync DB reading a bit more flexible

Dan McGee dpmcgee at gmail.com
Mon Jun 27 08:04:10 EDT 2011


On Mon, Jun 27, 2011 at 4:36 AM, Allan McRae <allan at archlinux.org> wrote:
> On 24/06/11 15:18, Dan McGee wrote:
>>
>> We can reorganize things a bit to not require reading a directory-only
>> entry
>> first (or at all). This was noticed while working on some pactest
>> improvements, but should be a good step forward anyway.
>>
>> Also make _alpm_splitname() a bit more generic in where it stores the data
>> it
>> parses.
>>
>> Signed-off-by: Dan McGee<dan at archlinux.org>
>
> Signed-off-by: Allan with minor query below.
>
>> ---
>>  lib/libalpm/be_local.c |    3 +-
>>  lib/libalpm/be_sync.c  |  130
>> ++++++++++++++++++++++++-----------------------
>>  lib/libalpm/util.c     |   46 ++++++++++-------
>>  lib/libalpm/util.h     |    3 +-
>>  4 files changed, 97 insertions(+), 85 deletions(-)
>>
>
> <snip>
> All the be_sync.c stuff looks fine to me.
>
>>
>> diff --git a/lib/libalpm/util.c b/lib/libalpm/util.c
>> index 4976703..e56c9f2 100644
>> --- a/lib/libalpm/util.c
>> +++ b/lib/libalpm/util.c
>> @@ -825,46 +825,54 @@ cleanup:
>>        }
>>  }
>>
>> -int _alpm_splitname(const char *target, pmpkg_t *pkg)
>> +int _alpm_splitname(const char *target, char **name, char **version,
>> +               unsigned long *name_hash)
>>  {
>>        /* the format of a db entry is as follows:
>>         *    package-version-rel/
>> +        *    package-version-rel/desc (we ignore the filename portion)
>>         * package name can contain hyphens, so parse from the back- go
>> back
>>         * two hyphens and we have split the version from the name.
>>         */
>> -       const char *version, *end;
>> +       const char *pkgver, *end;
>>
>> -       if(target == NULL || pkg == NULL) {
>> +       if(target == NULL) {
>>                return -1;
>>        }
>
> Should we check name/version/name_hash here for being NULL and abort similar
> to what was done for pkg previously?  Or could it be of use for this
> function to be called with those as NULL?
I didn't null check here because
1) Look later in the function; we only set version and name if they are non-NULL
2) in reality, the current two callers guarantee non-NULL for those
arguments, so even that might be overkill.

-Dan


More information about the pacman-dev mailing list