https://bugs.kde.org/show_bug.cgi?id=431223
--- Comment #8 from Christoph Cullmann <cullm...@kde.org> --- (In reply to Albert Astals Cid from comment #7) > (In reply to Dominik Haumann from comment #6) > > I second that: Without Kate being able to access arbitrary tools, Kate's > > functionality will be very limited, and we'll get bug reports about it. > > > > Packaging git is not the correct approach. Can't access to the system simply > > be granted somehow? > > No, you can't get access to the system binaries. > > We can remove kate from flatpak if you want, but yes, packging git and all > the dependencies kate needs is the correct approach, kate needs git, so kate > has to include git (or the base-kde-runtime it uses would need to include > git, but it doesn't because it doesn't make sense). how can otherwise kate > know that git is available? Then I think removing is the only option. For the version control: If one has local git stuff, we assume you have git, same if you have Mercurial repositories, naturally you will have Mercurial installed. It would be strange that installing Kate requires that all these things are installed, even if you don't use them. Naturally, we could improve the runtime error messages, thought for Flatpak that won't help, if there is no way to ever access that stuff even if the user installs it. Same for the LSP stuff: naturally, we don't want that Kate requires that you have OCaml/clang/Perl/Go/Rust/.... installed. Nor does it help to bundle all this, given you normally have some own versions required for your projects, therefore we must rely on the fact what is in the path. I think a KWrite Flatpak is fine, but for stuff like Kate it doesn't work out. (guess same for KDevelop/...) Actually, if it can't access the outside, stuff like the internal terminal and the external tools are even more affects, as we don't know what people want to use/configure there. -- You are receiving this mail because: You are watching all bug changes.
