D14486: Update to current mdbtools

[Jarosław Staniek]

staniek added a comment.


  Thanks for spending time on this Pino. If I can fix something at KEXI side it will cost us less. KEXI release do not trigger mbbtools release, that's #1 problem: nothing to do unless I switch to working on mdbtools, I do not say it's not possible, but KEXI has tons of such, some of them are below the tip of the iceberg visible for Debian users.
  
  I can tell you stories coming from actual user base. Debian flavor is small percent of our specialized OS universe... Ubuntu is also small but way bigger, neither of the OSes provide upgrades for MDB tools outside of the unstable line or custom installation package (that's only for power users). So the real fix is not only at our side. Ubuntu LTS is ultimate issue on top of that. Users are for example not willing to abandon "LTS" (advertised to them as "long term support"), and then loose MDB support in KEXI, and thus loose opportunity to KEXI for their purpose.
  
  Someone at the mdbtools level itself devoted to splitting to orthogonal elements could help. He would make mdbtools.h indpendent of exporting features, backend, odbs and other things.
  
  On KEXI side it's not likely that there are funds for contributing back to mdbtools - there are not many public projects of mdbtools as you already know. In KEXI there are no funds to even contribute to features in the mdbtools copy but still, by having a copy I reserve this possibility - to add a feature or fix _quickly_ in the same KEXI release, not in some distant future. Even if it's "just" building Android port - how could the vanilla mdbtools support our use cases if it's so small project? We could not be so harsh to request anything.
  
  I am sorry but this approach has been proven to be practical even if not right at academic level. There well requests to integrate similar code with Rekall and Knoda. Both projects are inactive to say at least. Furthermore I personally lost time and money even on barcode libraries here within KDE, e.g. on porting to libPrison.
  
  We also have another copy and that's a full fork proved to be right thing: KReport is a fork of OpenRPT. Where it is (a Qt 5 port) in Debian? Non-existing. We did nothing to contribute there but why would we have to? There are no usable contributions to KEXI of this sort - from other projects.
  
  These stories are all about very specialized subprojects or features that we depend on... Most usual users are closed source ones.

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/0e226246/attachment.html>