[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdelibs-bugs
Subject:    [frameworks-kio] [Bug 353642] kio master conflicts kde-baseapps 15.08.x
From:       Harald Sitter via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2015-10-27 7:14:53
Message-ID: bug-353642-90985-Vy8THId1s8 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=353642

--- Comment #6 from Harald Sitter <sitter@kde.org> ---
> Sounds fine. But if I understand Harald correctly, then it would have to be \
> kio5/kde-new-file-templates or kde-new-file-templates5 or something else that \
> contains a version number, in order to prevent that we get the same kind of \
> conflict when there will be a "KIO 6.x".

Exactly. We'd otherwise conflict between kio5 and kio6. Since we probably want
a soft transition from 5 to 6 we ought to avoid conflicts.
On a from-source-install level this isn't a big deal (except for maybe losing
translations if kio5 is installed/updated after kio6 is installed). Since
binary distributions have builtin mechanisms to prevent one package from
installing the same files as another package, for distributions this
constitutes a file conflict that needs to be solved by a human by either
packaging measures or creative patching of kio5.

That being said, not having a versioned path probably would be handy. Of the
top of my head there's two ways this can be done to make everyone happy:

1) create a standalone tarball/repo which is tier0 as it were and only installs
the templates. Between 5 and 6 its v5 incarnation can simply be dropped for v6
since they'd be interchangeable.

2) kio5 installs to PREFIX/share/kde-newfile-templates *UNLESS* cmake is run
with -DNO_INSTALL_TEMPKATES=ON. This in the end still requires a human to do
something to deal with this for binary distributions, but they'd have a very
clear path of how to do that (either rebuild kio5 without the dir, or package
such that the dir doesn't conflict).

Option 1 would be preferred seeing as it avoids the problem entirely by being
fully interchangeable between 5 and 6. 

> > 2) We need to make sure to adapt everything that was assuming
> > share/templates.
> If there is something in non-frameworks locations, like Plasma or KDE Applications, \
> then we might have another problem that is very hard to solve cleanly :-(

Tried lxr, but failed to come up with a suitable enough query :(. I think a
very nifty grep would be the most feasible approach to this. Other than that we
could have an opt-in kio cmake switch that installs a symlink from
share/templates to share/kde-newfile-templates to provide a compatibility gap
closer where needed; not sure that would be all too useful though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Kdelibs-bugs mailing list
Kdelibs-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdelibs-bugs


[prev in list] [next in list] [prev in thread] [next in thread]