D14486: Update to current mdbtools

[Jarosław Staniek]

staniek added a comment.


  > you cannot complain that mdbtools is not much used, if what KEXI currently does is actually part of the reason why mdbtools is not used much.
  
  I do not complain :) mdbtools, like many KEXI features or like genome sequencing software, etc. are *all* not much used by the nature of this software. Even many of the KDE contributors asked did not see such type of software as category or part of KDE (sw system that is not an SQL db backend). Not a complaint here, it's natural. It's expected to get more contributions to image viewers, icon grids (desktops) or file managers since there's the sweet point.
  
  > Considering somebody else other than you invested their time in updating the embedded copy (i.e. this differential revision), then it is just matter of adding the build system knobs to use a system library. After all, both the update of the embedded copy and the switch to the system library will require careful testing, so there is no difference nor increase in work needed from this POV.
  
  
  
  1. Embedded copy only = forced 1 version per release, on M platforms, controlled upgrade
  2. Embedded copy + allowing upstream = N+1 versions, where N is number of upstream versions on these M platforms (no control over this at all, can be that some platforms has no mdbtools at all). (mdbtools is very unlike popular dependencies)
  
  From the top perspective: KEXI has D dependencies consisted of rare and barely/slowly evolving software that is out of control; well, it is even able to use unreleased Java dependencies with strict version of Java needed; each single release of KEXI can have many more than D incarnations of dependencies even on single platform. There is no problem with major dependencies (but even Qt is not 100% green - 5.10.x generates issue like printing broken for 1 to 2 months until a fix appears) but for rare dependencies it's practically impossible to reproduce real combination of KEXI+system_dependencies - user base is so fragmented. In this workflow, package authors are disconnected from testers - and I am not complaining but stating this, as something very different to closed+commercial development.
  
  Reduction of permutations is why I've observed that users were happy with monolytic Appimage - they get exactly the software KEXI authors had on their tested at least for some time. I also do not see popular embedded and mobile platforms doing anything else than embedding custom dependencies.

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/20180730/23e60910/attachment-0001.html>