> On Nov 28, 2016, at 9:28 AM, Alexander Kanavin > <alexander.kana...@linux.intel.com> wrote: > > On 11/26/2016 01:07 AM, Jeffrey Johnson wrote: >> FWIW, your invitation expired or is otherwise unusable (but at least >> I can read your code, todo++). > > Yeah, I pressed the button on github and only then figured out that it's just > for allowing you to write to my repository, and then I withdrew the invite. > We can publish and share all work via your rpm5 repos. >
Good: let a dnf -> rpm5 collaboration congeal! ;-) >> You have chosen to fork libhif from >> rpm-software-management/libhif >> <https://github.com/rpm-software-management/libhif> >> rather than a fork (of a fork) from >> https://github.com/rpm5/libhif >> >> That forces our coordination to be pulled from the only common >> root at >> rpm-software-management/libhif >> <https://github.com/rpm-software-management/libhif> >> which almost certainly precludes any participation from me and rpm5.org >> <http://rpm5.org> >> for various reasons. > > libhif has been in active development lately (51 commits ahead of your repo), > and so I wanted to use their latest code as a starting point. Also your repo > has a single commit that seems to be incomplete and squashing together > several unrelated fixes (without documenting them) [1]. Can I move that > commit to a 'jeff' branch, so the master branch contains only proper commits > and is updated from upstream regularly? > Yes, there were quite a few checkins since I created the forks. I updated all the repositories that did not need merging this weekend (but that wasn’t libhif). Make yourself happy with libhif: all of my work was largely exploratory assessing what issues need to be solved. Feel free to clobber anything I checked in to start getting an easily updated master branch. I’ll create a “macports” branch for my MacPorts efforts going forward. Meanwhile its likely time to establish some structural cmake parameters for porting use like #ifdef RPM5 and #ifdef MACOSX on rpm5:master. The exploratory work identified several common porting issues: 1) #include <rpm/rpmlib.h> vs #include <rpmts.h> The issue is whether includes should have directory structure. RPM5 is going to need to build both in-tree and out-of-tree, and (imho) this is best dealt with using a -I/usr/include/rpm path in CFLAGS. But we can #ifdef RPM5 around includes for now. 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 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. 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. Its also likely time to get the python subdirectory out of rpm5.org CVS and into a github.org/rpm5 repository. rpm-python SHOULD be its own project/repository, it was added to rpm CVS solely because of expediency last century. > [1] > https://github.com/rpm5/libhif/commit/1515ca9e9669a4c65caccb38cbe578775c63f282 > >> Note that there are several other efforts attempting a dnf->…->rpm5 tool >> chain that I >> am aware of. Which is why I attempted RPM5 repositories to permit >> collaboration, and >> am perfectly willing to give write access to anyone who wishes. >> >> I am also perfectly willing to let someone other than rpm5.org >> <http://rpm5.org> administrate the mess if that >> is what is desired. I do encourage all of you to collaborate early and >> work forward from >> working tools. There’s a fair amount of subtle work that will be needed >> imho. >> What is your intent: collaboration with rpm5.org <http://rpm5.org> or >> collaboration with rpm-software-management? > > My idea is that once we get something working in rpm5 repositories and have a > reasonable set of commits, I can try to approach rpm4 people with those > patches (you don't have to be involved in that). If they agree to take them, > great, if not, we'll figure out some way to maintain them separately. > Good luck! >> Um rpm5.org <http://rpm5.org> and rpm.org <http://rpm.org> have >> different API’s, and are most definitely different >> implementations these days. Its not just include files, and more than >> libhif is going to >> be needed to build a working dnf->…->rpm5 tool chain. > > Yep, but let's start with libhif and its build errors. > Actually, some of the other ports (like createrepo_c) are rather easier and can be pursued in parallel as long as the focus is still on the libhif as the critical path. (aside) btw, this thread likely should be moved to <rpm-de...@rpm5.org>, I’ve added a CC … *shrug* hth 73 de Jeff > > Alex > ______________________________________________________________________ > RPM Package Manager http://rpm5.org > User Communication List rpm-users@rpm5.org ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List rpm-users@rpm5.org
