D14486: Update to current mdbtools

[Pino Toscano]

pino added a comment.


  In D14486#300844 <https://phabricator.kde.org/D14486#300844>, @staniek wrote:
  
  > In D14486#300823 <https://phabricator.kde.org/D14486#300823>, @pino wrote:
  >
  > > Instead of updating the embedded copy of mdbtools, why not just switch to an external/system copy of it? This way tasks like T1361: Update to current mdbtools (July 2018) <https://phabricator.kde.org/T1361> will not be needed anymore (and your distro packagers will be happier).
  >
  >
  > Hi Pino, we're getting such questions from time to time. mdbtools, as a great project that supports obsolete MS tech (according to MS itself), it is not mature (or widely used) enough to be versioned properly, separated to functional nonGUI/GUI parts, have BC in mind, all what's requirement of proper packaging. We're not eager to see KEXI depending on GTK+... glib is enough issue.
  
  
  Regarding the dependencies: the `libmdb2` library package in Debian and derived distros, generated from the mdbtools source, depends only on glib; GTK+ seems to be used only by gmdb2, which is only one of the tools.
  
  Regarding the stability: `libmdb.so` has the same SONAME since its introduction in mdbtools 0.7, released 6 years ago, so IMHO there are no concerns about the BC/API stability (or they are low).
  
  Regarding the maturity: of course, this is a "dog that chases its own tail" issue: if projects embed mdbtools instead of using a system copy, of course the upstream project is tested less. In Debian I found 3 projects using mdbtools:
  
  - kexi: uses its own embedded copy
  - libgda (http://www.gnome-db.org/): uses its own embedded copy
  - recutils (http://www.gnu.org/software/recutils/): optionally uses a system version (no embedded copy)
  
  Obviously I cannot scientifically prove it, but I'm fairly sure the quality of upstream mdbtools would improve if both kexi and libgda switched away from their embedded copies.
  
  Also, the Debian packaging has a couple of backports of fixes from upstream: since I package kexi in Debian, I really do not want to start doing this same job (i.e. backport fixes from another upstream) -- using the system copy means that I almost do not need to care, or if I do then fixing mdbtools will do the job.

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/70b164e9/attachment-0001.html>