On Dec 30, 2010, at 10:17 AM, Silvan Calarco wrote:
> On Tuesday 28 December 2010 18:10:43 Jeff Johnson wrote:
>> SO instead of headerGetEntry() the replacement becomes
>> something like this (this is my paradigm anyways, adjust to tate
>> if you dislike using alloca):
>>
>> HE_t he = memset(alloca(sizeof(*he)), 0, sizeof(*he));
>>
>> he->tag = RPMTAG_NAME;
>> if (headerGet(h, he, 0) && he->t == RPM_STRING_TYPE && he->c == 1)
>> *np = xstrdup(he->p.str);
>> else
>> *np = NULL;
>> he->p.ptr = _free(he->p.ptr);
>
> Ok, this implementation looks more clear than before about data allocation.
Yep, "clear" was the goal, and to remove headerFreeData().
> I replaced all the calls to headerGetEntry with a call to each of the
> following per-type functions:
>
>
<snip> Yes that works.
(aside)
The design problem is that a data type isn't too useful for RPM.
Sure all the primitive string and integer and octet
(and scalar/array) data types exist in RPM.
But (with one hysterical exception -- RPMTAG_ARCH/RPMTAG_OS,
which have morphed integer -> string) -- the data types have
never been used in RPM because the tag name implies its type.
You've also seen the segfault pain from
RPM_CHAR_TYPE -> RPM_UINT8_TYPE
(which is hardly an interesting or important change).
So you might want to rethink your API down the road.
> Not perfect but it apparently works without regressions (tested with the
> whole
> openmamba repository), anyway I'll consider doing a valgrind check later.
Good. Note that rpm-5.2.1 has private memory pools, which required
some annotations to use valgrind, so you likely want to make
sure that rpm is built --with-valgrind.
> Next came apt 0.5.15lorg porting. Though openmamba is using smart which works
> without changes because it uses python-rpm, apt libraries are still used e.g.
> for repository tools. I've built version 0.5.15lorg3.94a using a couple of
> patches I found, one for rpm5 and the other to fix a crash around lua code.
You might want to talk to Andre Guerreiro at Caixa Magica. Per Oyvind
(who also wrote <rpm4compat.h>) has a git repository somewhere with
apt-rpm ported to @rpm5.org code.
It sure would be nice (for "support") if you all started using the same
version of apt-rpm and otherwise shared development efforts.
> Well apt-get doesn't do anything yet, but I can go on with porting its
> dependant packages and test them later.
> The last one was apt-repo-tools (http://sisyphus.ru/en/srpm/Sisyphus/apt-repo-
> tools) which I use to replace genpkglist and gensrcpkglist from apt, just
> ported with some fixes. Now I'm ready for a test of the whole thing on the
> repository side...
Two asides:
1) I have the start of a functionally equivalent replacement for
genpkglist/gensrcpkglist written in C. I can finish writing those
two tools (in C using POPT) with c couple of days of work if there's
interest. My interest at the time was studying what Debian uses
for repository markup as well as fro POPT development (I also maintain POPT).
2) RPM has something called "queryformat templates" in /usr/lib/rpm/qf/*
that can be used to generate markup based on package metadata.
E.g
rpm -qq --yum:primary.xml
is essentially the XML that YUM uses. There's some Debian derived
markup there too. Note that I have no usage case for Debian package
markup in RPM. I was interested in seeing whether --queryformat
templates can be used for "real world" markup spewage. My answer:
Yes, queryformat templates will "work" for markup.
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
