https://bugs.kde.org/show_bug.cgi?id=406712
--- Comment #2 from avlas <jsar...@gmail.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
