On 11/28/2016 06:35 PM, Jeffrey Johnson wrote:
2) There are several repetitive cosmetic (but annoying) API differences.
These problems could (almost) be handled with some #defines
* the “match iterator” rpmmi* interface for rpmdb retrieval
* the “problem set” rpmps* interface for problem sets
As far as libhif build errors related to these differences go, a
rpm46compat.h include seems to deal with them.
I'm not sure if this is the right thing to do, because I don't know how
supported that compatibility layer is, and also it produces a duplicate
declaration error instead:
| In file included from
/home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/include/rpm/rpm46compat.h:10:0,
| from
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-rpmts.c:39:
|
/home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/include/rpm/rpm4compat.h:354:21:
error: static declaration of ‘fdSize’ follows non-static declaration
| static inline off_t fdSize(FD_t fd){
| ^~~~~~
| In file included from
/home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/include/rpm/rpm4compat.h:52:0,
| from
/home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/include/rpm/rpm46compat.h:10,
| from
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-rpmts.c:39:
|
/home/ak/development/poky/build/tmp/sysroots/x86_64-linux/usr/include/rpm/rpmio.h:543:9:
note: previous declaration of ‘fdSize’ was here
| off_t fdSize(FD_t fd)
| ^~~~~~
What would you suggest?
3) Some rpm.org interfaces are intractably different and mostly useless for RPM5
* the “tag data” rpmtd*
* the rpmkeyring* pubkey handling
While these interfaces have been merged into rpm5 libraries (rpmtd for
python bindings,
rpmkeyring just in case), that isn’t/wasn't the best engineering
because RPM5 itself
doesn’t use or need or test those interfaces. The better approach going
forward (imho)
will be to refactor those api’s somewhere other than in rpm5 libraries.
I don’t yet
know what to do with those apis, but I’d like _NOT_ to be forced to
maintain
multiple divergent/redundant API’s in RPM5 simply to support a dnf (or
rpm-python) port.
rpmtd and rpmkeyring are used in various places around libhif - I didn't
look yet how exactly, but they are a serious blocker.
A couple other issues I see:
1)
|
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-rpmts.c:
In function ‘dnf_rpmts_get_problem_str’:
|
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-rpmts.c:241:10:
error: ‘RPMPROB_OBSOLETES’ undeclared (first use in this function)
| case RPMPROB_OBSOLETES:
| ^~~~~~~~~~~~~~~~~
2)
|
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-context.c:
In function ‘dnf_context_get_base_arch’:
|
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-context.c:297:5:
error: implicit declaration of function ‘rpmGetOsInfo’
[-Werror=implicit-function-declaration]
| rpmGetOsInfo(&value, NULL);
| ^~~~~~~~~~~~
|
/home/ak/development/poky/build/workspace/sources/libhif/libdnf/dnf-context.c:299:5:
error: implicit declaration of function ‘rpmGetArchInfo’
[-Werror=implicit-function-declaration]
| rpmGetArchInfo(&value, NULL);
| ^~~~~~~~~~~~~~
Meanwhile:
Are you able to build the RPM5 rpm-5_4 branch from CVS?
That is likely needed pretty soon. I can help as necessary.
Openembedded build system is currently packaging rpm 5.4.16 (plus a lot
of custom patches). I can check out the latest CVS separately and cherry
pick needed commits from there as needed (and append them to the list of
custom patches), if that is okay.
Otherwise, Mark Hatle needs to provide me with a working rpm recipe that
is taking latest CVS code. I'll ask him now.
(aside)
btw, this thread likely should be moved to <rpm-de...@rpm5.org>, I’ve added a
CC … *shrug*
I'm CCing this message to rpm-devel too, the following messages will go
to rpm-devel only.
Alex
______________________________________________________________________
RPM Package Manager http://rpm5.org
User Communication List rpm-users@rpm5.org
