KDE neon should not apply strong dependencies on cantor backends, as users may have those applications from elsewhere (flatpak, snap, or own compilation). I workarounded this by modifying the control file of the deb package. Please see https://bugs.kde.org/show_bug.cgi?id=406684#c2 for a context in which this is important. In short, ubuntu repos only offer 4.x versions of octave, which are discouraged, so I use the up-to-date stable version (currently Octave 5.1) via a flatpak container.
That would also allow "breaking" cantor, which as far as the deb dependency line-up is concerned is not something that should be allowed. Mixing the stack like this simply isn't going to work I expect, it'd mean that the various distributions mechanism needs to be aware of one another (which they are not) or to allow the distribution mechanisms of disobeying requirements (which they should not).
(In reply to Harald Sitter from comment #1) > That would also allow "breaking" cantor, which as far as the deb dependency > line-up is concerned is not something that should be allowed. I respect what you say but I would argue just the contrary. As a scientist/engineer dev I see it the other way around. Current state may not "break" Cantor structurally, but it does "break" Cantor functionally, which ultimately is more important, because the ultimate user (either a researcher, a instructor or a student dev) expects to use a backend according to upstream decisions of that backend (for instance, the first thing Octave devs say when having issues is to install latest stable, obsolete versions are discouraged and not supported). Also, I think you are wrong in the sense that eliminating the dependency does not actually "break" anything. I actually did it myself modifying the control file of the deb (sth not every user knows how to do, or wants to do after each update). Cantor "does just fine" filtering out that backend at startup. There is room for improvement on Cantor's end to this respect actually: https://bugs.kde.org/show_bug.cgi?id=406779 This is something, Cantor's devs seem to agree on, btw. In summary, I disagree with the decision made here. Note though that I have a way to workaround it, so for me it is a matter of comfort (modifying the control file of the deb file after each update or not), but all of the above is to advocate for other (potential) users of Cantor, so they can use the software in the best way possible.
In fact, Cantor backends are plugins/addons. There are many applications out there that do the same without breaking the application. For instance, Okular has recently introduced support for TexStudio as editor and this has been highlighted in 19.04 release as a big deal. It is perfectly fine to install Okular, including these plugin functionality embedded without installing TexStudio. This is because in general applications support plugins, even though plugins may not be automatically functional without configuration (e.g., setting a command, or a path to an executable, which is exactly the same for Cantor). Cantor already supports that.
(In reply to Harald Sitter from comment #1) > That would also allow "breaking" cantor, which as far as the deb dependency > line-up is concerned is not something that should be allowed. Mixing the > stack like this simply isn't going to work I expect, it'd mean that the > various distributions mechanism needs to be aware of one another (which they > are not) or to allow the distribution mechanisms of disobeying requirements > (which they should not). Would you please reconsider your decision once Cantor 19.08 is released? Please see https://bugs.kde.org/show_bug.cgi?id=406779#c2
Another notorious example to compare to: Online accounts in system settings displaying ownCloud and Twitter. With respect to the decision about Cantor, this doesn't seem to be very coherent: - ownCloud is presented as an option even if nothing related to it is installed in my system. You click on it and it opens a menu so you can configure it (exactly what I request for Cantor). Only that if you cancel, instead of quitting gracely, it breaks system settings awaiting a response that never happens. - twitter: no idea what this is, I clicked on it, and nothing happens beyond the indicator that system settings is stuck awaiting for something... which sounds like the "twitter" component is "breaking" system settings. Anyways, I decided to build Cantor on my own instead of using neon packages and having to change dependencies all the time. I mark this bug as resolved intentional instead because I think it is better classified. Not a bug is arguable, but intentional is very clear, you don't have the intention to modify this following your fuzzy logic, which I respect even though I don't share.