> On Nov 29, 2016, at 9:49 AM, Alexander Kanavin
> <alexander.kana...@linux.intel.com> wrote:
>
> 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?
>
The fundamental issue is that <db46compat.h> can only provide compile time API
compatibility.
That’s fine for apparently simple projects that only need, say, to read a
package header, and print
some scalar tags.
I use “simply” advisedly. Reading a digitally signed package header requires a
pubkey from
somewhere, and the original RPM API from last century has no easy means to make
that pub key
magically/transparently appear.
There are deeper issues with ABI compatibility and rpmdb retrieve and rpm
configuration
that <db46compat.h> cannot address.
Meanwhile many trivial incompatibility solutions can be found in <db46compat.h>.
But the better engineering for a port as large and complex as DNF should not
(imho)
be attempted through the false hope of
#include <db46compat.h>
>> 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.
>
For now, comment out all keyring handling and pubkey management in DNF: RPM5
libraries
have MANDATORY signature verification (and automated pubkey retrieval) on the
common
package header I/O path. A better longer term will have to be postponed until
DNF is sufficiently
functional because there are different POV on what “trust” means wrto package
management.
(aside)
For starters, RPM5 uses keyutils(8), which has some hope of refactoring _ALL__
pubkey
management out of _ALL_ RPM tool chains by writing a helper that is invoked by
the
keyutils async callback.
The rpmtd interface is present in -lrpmio for the python bindings. The longer
term fix will be
to move the rpmtd* API Somewhere Elese Insead, possibly by adding an #ifdef
RPM5 compatibility
shim.
> 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:
> | ^~~~~~~~~~~~~~~~~
>
Use #ifdef RPM5 for now
> 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);
> | ^~~~~~~~~~~~~~
>
These are part of the rpmrc API. The short term porting fix is just to hardwire
useful strings.
The better RPM5 fix is to read the first line of /etc/rpm/platform and split
CPU-VENDOR-OS-GNU
for OS and CPU.
>
>> 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.
>
I can walk you through setting up a build from RPM CVS (and likely have to walk
Mark Hatle through same ;-)
The Yocto rpm-5.4.16 “system” RPM can be used for now. But having a full RPM
CVS build
will be needed to use additional functionality: RPM5 (deliberately) does not
expose all include
files.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
