RPM Community Forums

Mailing List Message of <rpm-users>

Re: Making rpm5 work with dnf

From: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Date: Tue 29 Nov 2016 - 15:49:51 CET
Message-ID: <b035a822-16f5-c58f-04d6-1ed7d499feee@linux.intel.com>
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 
|                  from 
error: static declaration of ‘fdSize’ follows non-static declaration
|  static inline off_t fdSize(FD_t fd){
|                      ^~~~~~
| In file included from 
|                  from 
|                  from 
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:

In function ‘dnf_rpmts_get_problem_str’:
error: ‘RPMPROB_OBSOLETES’ undeclared (first use in this function)
|           ^~~~~~~~~~~~~~~~~

In function ‘dnf_context_get_base_arch’:
error: implicit declaration of function ‘rpmGetOsInfo’ 
|      rpmGetOsInfo(&value, NULL);
|      ^~~~~~~~~~~~
error: implicit declaration of function ‘rpmGetArchInfo’ 
|      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-devel@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.

Received on Tue Nov 29 15:49:49 2016
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.