> On Nov 30, 2016, at 7:42 AM, Alexander Kanavin > <alexander.kana...@linux.intel.com> wrote: > > On 11/29/2016 06:31 PM, Jeffrey Johnson wrote: >> 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> > > Alright. Let's drop the include and solve the issues the hard way. >
The API compilation issues aren’t all that hard, nor is the connection to rpm libraries in C pervasive The hard issues are going to be changing dnf to handle arbitrary tags and mandatory signature verification and transactions from RPM5 intelligently, and identifying equivalent implementations for SELinux and rich dependencies from rpm.org. >> 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. > > Maybe it's possible to provide empty keyring functions to substitute for > their absence in rpm5 - that way we can avoid having #ifdefs all over the > place. I'd like to use #ifdefs sparingly, they make the code harder to read > and maintain. > No need for stubs: there are rpmie/rpmkeyring.[ch] ramie/rpmtd.[ch] already in RPM5. But like <db46compat.h>, none of this code is used or tested by RPM5 and cannot be maintained unilaterally within RPM5 for many reasons, not the least of which is that these are _NOT_ RPM5 interfaces, and are a huge impediment to, say, deploying mandatory signature verification in RPM5. >> 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. > > Yeah, I need to check what rpm4 does here. > Both rpm4 and rpm5 support /etc/rpm/platform containing CPU-VENDOR-OS-GNU >> 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. > > We actually used to have a rpm-from-cvs recipe in openembedded build > environment, but it got removed for some reason. Maybe I can bring it back; > I'd like to avoid developing on the host. > Develop as you wish … … meanwhile my main interest is RPM5 not DNF, nor a port. I can deliver a fix through CVS much more easily than going through a patch release through Yocto. YMMV. 73 de Jeff > Alex > > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > Developer Communication List rpm-devel@rpm5.org ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
