D14486: Update to current mdbtools

[Adam Pigg]

piggz added a comment.


  In D14486#300988 <https://phabricator.kde.org/D14486#300988>, @staniek wrote:
  
  > In D14486#300962 <https://phabricator.kde.org/D14486#300962>, @pino wrote:
  >
  > > In D14486#300951 <https://phabricator.kde.org/D14486#300951>, @pino wrote:
  > >
  > > > > so your is proposal correct but of a very low priority for me.
  > > >
  > > > Considering somebody else other than you invested their time in updating the embedded copy [...]
  > >
  > >
  > > Sorry, I have to stand corrected by myself: you were the one doing this update. OTOH, the rest of my message still stands.
  >
  >
  > Of course this shall be a member of KEXI project because mdbtools is not a general purpose solution designed to plug to other GUI apps so easily. It's consisted of set of command line tools (they are always hard to integrate with a front end in other than naive way) or has some hard coded GUI, plus C APIs for all these needs exposed in one relevant header file. API stability through the fact that the header rarely changes is accidental.
  >
  > Disclaimer: mdbtools is one of best reverse engineering projects I know and one of most important to me. Reverse engineering is the core of it, the rest is "just" necessary thing IMHO.
  >
  > I can assure you that updating mdbtools, unlike sqlite (which is just big enough that it is fine grained and more general purpose), needs to be performed patch-by-patch. Long ago it was the same story with SQLite (version 2 vs 3, breaking compatibility after 3.0, and so on). Since then sqlite is used on every mobile phone and mdbtools is used, you know how frequently.
  >
  > It's not just a separate situation. I can recall the story of issues that Okular had with (IIRC?) PDF backends. Or Krita with touch input device support in Qt. These projects were not even able to fork the dependencies, I guess mainly because of the size but number of workarounds added was noticeable. Of course we do not argue that forking or embedding is not a really unclean solution, but it's not true that it's not happening, just like it's not true that there are thousands of projects that use years old compilers.
  >
  > Here in keximdb nothing changes for you as package author, right? When this patch gets integrated into KEXI there is the same situation from the packages' POV as you it was years ago.
  >
  > If otherwise I just delegated the risk and testing to users (not packagers, since as we know they do not have just one project to support and are rather project-agnostic) it isn't impossible that packagers would have to know that we request version 0.7.1 supported and not >=0.7.2 for some compatibility or "exceptional" reason. I can't imagine how this contract can be assured distro-independently with tool we have not which is just a plain README file and so limited developer workforce. It's possible that users will have KEXI 3.1 running on their desktop 4 years later and mdbtools package completely unknown to us. Part of the issue come from the fact that we reserve right to use mdbtools not the way it was designed, to get all kind of instrumentation we need.
  >
  > Jokes: I do not know how it is possible that chromium or Libreoffice or Firefox is packaged as larger monolytic packages (they both contain lots of unrelated tech compiled together). Or MySQL. Why the MySQL parser is not separate package so I can use it...
  
  
  A few questions, in the interest  of keeping our downastream happy, and potentially reducing our burden
  
  1. do we carry patches ontop of mdb?
  2. how much work would be neded in adding a switch to use the system lib?
  
  --I know this would initially be a little work, but could allow a phased approach to using the system supplied lib over time, as packagers choose.  If after 1-2 years, all packagers are onboard, we could then make it the default and remove our version of mdb, and the need to maintain it.

REPOSITORY
  R71 Kexi

REVISION DETAIL
  https://phabricator.kde.org/D14486

To: staniek, piggz
Cc: pino, Kexi-Devel-list, clybekk, barman, staniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kexi-devel/attachments/20180731/2df6faa5/attachment.html>