[Rpm-maint] [PATCH 2/2] Recognize "<epoch>:" as a part of a label (ticket #117)

Panu Matilainen pmatilai at laiskiainen.org
Tue Nov 15 09:37:04 UTC 2011


On 11/11/2011 01:09 PM, Ales Kozumplik wrote:
> - for instance this works now:
>    $ rpm -q perl-4:5.14.1-188.fc16.x86_64
>    perl-5.14.1-188.fc16.x86_64

Okay, for what I tested it works fine, including this special case that 
wasn't even specified in the ticket:

[pmatilai at localhost rpm]$ ./rpm -q --qf "%{nevra}\n" libtdb
libtdb-1.2.9-10.fc16.x86_64
[pmatilai at localhost rpm]$ ./rpm -q libtdb-1.2.9
libtdb-1.2.9-10.fc16.x86_64
[pmatilai at localhost rpm]$ ./rpm -q libtdb-0:1.2.9
libtdb-1.2.9-10.fc16.x86_64

Ie packages with no epoch is treated equally to epoch of zero - this is 
how we want it. Good.

One nit on the implementation though (see below)...

> ---
>   lib/rpmdb.c |   58 +++++++++++++++++++++++++++++++++++++++++++++++++---------
>   1 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/lib/rpmdb.c b/lib/rpmdb.c
> index e249998..4c0af2d 100644
> --- a/lib/rpmdb.c
> +++ b/lib/rpmdb.c
> @@ -118,6 +118,29 @@ static unsigned int uintId(unsigned int a)
>   }
>
>   /** \ingroup dbi
> + * Return (newly allocated) integer of the epoch.
> + * @param s		version string optionally containing epoch number
> + * @retval version	only the version part of s
> + * @return		newly allocated epoch integer
> + */
> +static int * splitEpoch(const char *s, const char **version)
> +{
> +    int e;
> +    int *epoch = NULL;
> +    char *end;
> +
> +    *version = s;
> +
> +    e = strtol(s,&end, 10);
> +    if (*end == ':') {
> +	*version = end + 1;
> +	epoch = rmalloc(sizeof(*epoch));
> +	*epoch = e;
> +    }
> +    return epoch;
> +}

Why the malloc? AFAICS you could just have "int epoch = 0" in 
dbiFindByLabel() and pass the pointer to that to splitEpoch(), only 
changing the value if one was actually found, equaling the "no epoch 
equals zero epoch" behavior and avoiding couple seemingly unnecessary 
malloc/free on what's a fairly busy path.

	- Panu -


More information about the Rpm-maint mailing list