D14486: Update to current mdbtools

[Pino Toscano]

pino added a comment.


  First of all Jarosław: thanks for the details -- OTOH, could you please be slightly a bit less verbose and more to-the-point? Thank you in advance.
  
  In D14486#300882 <https://phabricator.kde.org/D14486#300882>, @staniek wrote:
  
  > 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:
  
  
  Likewise, a KEXI release does not trigger a release of KF5, nor Qt5, nor anything else that KEXI uses.
  
  > 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.
  
  While this is something I'm aware of, and I can understand, this is totaly unrelated to the issue at hand.
  Also, there is a bit of FUD in the paragraph above -- still, unrelated to the issue, so I will ignore it.
  
  > 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.
  
  Were these needs asked to the mdbtools upstream?
  
  > 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.
  
  As above: for the same reasoning, you would then embed KF5, Qt5, etc, just because of the "possibility" to fix quickly anything in them.
  Or where do we draw the line here?
  
  > I am sorry but this approach has been proven to be practical even if not right at academic level.
  
  This has nothing to do with "academic level".
  
  > 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.
  
  Honestly, I would not consider //one// example as //the// example.

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/858c664e/attachment.html>