[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:       Frank Reininghaus via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2015-10-28 19:54:45
Message-ID: bug-353642-90985-9iYf0MM7rY () http ! bugs ! kde ! org/
[Download RAW message or body]

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

--- Comment #7 from Frank Reininghaus <frank78ac@googlemail.com> ---
(In reply to Harald Sitter from comment #6)
> That being said, not having a versioned path probably would be handy. 

Yes, I agree. A version in the path bears the risk that stuff will break if the
version changes, and the path is not updated everywhere.

> 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.

I didn't even know that a tier 0 exists :-)

This might be a solution. It will require some effort though, and I'm not sure
if it could be done before the next frameworks release.

> 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).

This is probably not a good idea. A user who notices the lack of the menu items
cannot know if the packager decided to set this option, and for the user, it
would be far from obvious how to resolve the problem.

> >> 2) We need to make sure to adapt everything that was assuming
> >> share/templates.

The more I think about it, the more afraid I get of changing the path in
multiple modules, especially changing it shortly before the planned tagging of
5.16 on November 7. Considering the (for me totally unexpected) trouble that
this apparently simple fix caused, I am not too optimistic about the outcome of
such an operation. I will be away for much of next week, so I might not be able
to do much about any possible problems.

Unless anyone has a very clever idea or is brave enough (and has enough spare
time) to proceed with one of the suggested approaches, I see only two quick and
easy solutions:

1. Revert the commit that adds the templates to KIO.

2. Rename the files that KIO installs, maybe by prepending their names with
"New". This will not solve the problem with a possible future transition to KIO
6.x though (unless we include the version number in the file names).

-- 
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]