ng0+guixpatches@n0.is writes: > On Fri, 26 Jan 2018, Kei Kebreau wrote: >> ng0+guixpatches@n0.is writes: >> >>> On Fri, 26 Jan 2018, ng0+guixpatches@n0.is wrote: >>>> On Fri, 26 Jan 2018, Kei Kebreau wrote: >>>>> * gnu/packages/maths.scm (octave)[inputs]: Add qscintilla, qt, suitesparse, >>>>> libsndfile, portaudio and alsa-lib. >>>>> [native-inputs]: Add qttools. >>>>> [arguments]: Add 'patch-qscintilla-library-name' phase. >>>> >>>> Woo! Nice :) I've started work on the Qt GUI a while ago but >>>> never finished it. Do you think we should split this into octave >>>> and octave-qt (or octave-gui)? Qt is quiet huge and not everyone >>>> will want this I think. >>>> >>>> Building this now and getting back to you with results. >>>> > […] >>> Build, compiled, installed, LGTM and works for me. At least the >>> minimal basics I've tested. >>> >> >> Excellent! Thanks for testing this. >> >>> However I still think we should split it later on. I'm not sure >>> if other systems just provide it in one piece or if they provide >>> octave-cli, octave-qt, etc. >>> In my scenario we don't have substitutes for Qt all the time and >>> someone running a >>> machine which isn't capable of building Qt wants to use octave. >> >> I agree that this package should be split. Should a split be made now >> while we leave the lighter CLI-only Octave package available on master, >> or should it be postponed until later on? >> > > It could be done later on, but if you think it wouldn't be too > much work you could do it now. Done, I think! > Ideally this would leave 'octave' as it is and add > 'octave-whatever' ... octave-qt? Debian calls the package (with > just the Qt Gui) "qtoctave". octave-* should be reserved for > extensions (which we don't have right now), so maybe qtoctave > would fit into our naming scheme? > > > / I think I'm going to switch the subscribed address once more, > now that I have proper filtering I don't need the server-side > filtering. / Can you (and/or any bystanders reading this) test these?