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
