D14111: Install MIME type definition for text/x-rst ourselves for now

[Pino Toscano]

pino requested changes to this revision.
pino added a comment.
This revision now requires changes to proceed.


  In D14111#291934 <https://phabricator.kde.org/D14111#291934>, @kossebau wrote:
  
  > In D14111#291933 <https://phabricator.kde.org/D14111#291933>, @pino wrote:
  >
  > > NACK.
  > >  Make sure that the request for shared-mime-info (https://bugs.freedesktop.org/show_bug.cgi?id=107227) is accepted, and that is enough.
  >
  >
  > Even if the request is accepted, it will take some time until it makes it to the users/developers, given smo 1.10 was tagged/released only some days ago, and as smo release cycle seems to be half a year or longer. Which in developer life is ages, especially looking at the web rivals, which deliver each months to everyone :/
  
  
  If that is problematic enough, talk with hadess (Bastien Nocera) about that.
  
  >> There is enough stuff in `kde5.xml` already, even shipped in shared-mime-info, so adding more is not a good idea.
  > 
  > Sure that needs some clean-up. I already started a patch to split this up and make things depend on the found smo version, so just the stuff is installed which is really needed.
  
  I thought about a similar approach in the past, but
  
  - unless you really maintain the amount of files, and properly tie each to a version of s-m-i, it becomes a mess to maintain
  - once you update s-m-i, you are back to a potential conflict (since the new s-m-i version may carry a new mimetype shipped in `kde5.xml`)
  - related to the point above: s-m-i is really a //runtime// dependency, so version checks at //build// time are not exactly good ideas...
  
  > Perhaps you can reconsider your take on this one once that has been uploaded and reviewed :)
  
  Not really: even if you implement what you mention above, the duplication is still there.
  
  Just to expand a bit more: when we switched to s-m-i during the kde4 development (more than 12 years ago), I took the task of migrating our mimetypes to the "new" format. Call it "mistakes of youth", "limitations of the toolchain at that point", etc, the result was a single `kde.xml` carrying all the mimetype definitions that kdelibs had, and that s-m-i had not. Some of the mimetypes were generic enough to be added to s-m-i, so they were included (see various commits with myself as author), and some were not (see the various "smi rejected" comments floating around). To overcome the lack of these mimetypes in s-m-i, they were added in `kde.xml`, because of the reasons you mention above. Soon though I realized it was not a good idea, since a) neither of the mimetypes were critical enough to warrant duplicates b) basically nobody else than @dfaure me maintained `kde.xml`. See for example the recent e5f09f84a945af4edf4f346aed409acf29905414 <https://phabricator.kde.org/R244:e5f09f84a945af4edf4f346aed409acf29905414>, which is one of the biggest cleanups after so many years. Or a7be6bab411d7f1fe2555ab5adc0465ca0cfc5d9 <https://phabricator.kde.org/R244:a7be6bab411d7f1fe2555ab5adc0465ca0cfc5d9>, i.e. synchronize a local copy of a s-m-i mimetype ...
  
  So yes, I understand your reasons, but because of all the history involved I really do not want to add more stuff to `kde5.xml` that is really material for s-m-i.

REPOSITORY
  R244 KCoreAddons

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

To: kossebau, dfaure, pino
Cc: fabianr, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180714/7d6a115e/attachment.html>