[GRASS-dev] CLI!=GUI

GRASS GRASS developer
1

Glynn ha scritto:

> If the only available packages (RPM, .deb, etc) insist
> upon installing GUI libraries, complain to the people who
> make the packages.

Paolo:

OK, so, now I'm complaining :wink: : packagers, please have
your saying here.

disk space is very cheap. package maintaining time is not. IMHO
unused libraries & a couple extra packages do no real harm &
where it does matter (embedded systems) the user will probably
want to custom build from source anyway. I do not much like the
idea of making the packaging scripts any more complicated than
absolutely needed. I do not much like the idea of e.g. the grass
debian package merely recommending the GUI be installed as well,
even if it is technically possible not to require it.

The rationale is: decoupling CLI and GUI will make the release
cycle smoother

I humbly suggest that in practice it will only complicate things
and add unneeded burden to the release manager(s).

From a code point of view they are decoupled already.

best,
Hamish

2

Hamish wrote:

> > If the only available packages (RPM, .deb, etc) insist
> > upon installing GUI libraries, complain to the people who
> > make the packages.

Paolo:
> OK, so, now I'm complaining :wink: : packagers, please have
> your saying here.

disk space is very cheap. package maintaining time is not. IMHO
unused libraries & a couple extra packages do no real harm

It isn't "a couple". Once you link against wx, you're looking at ~60
extra libraries.

I'd suggest that the core GRASS package shouldn't list X, wxWidgets or
(in 6.x) Python as dependencies.

It shouldn't be necessary to split the actual GRASS distribution into
GUI and non-GUI components. Put everything in the non-GUI package, and
have a separate GUI package which is empty (or contains a single dummy
file if the packaging system doesn't allow empty packages) and exists
solely to hold the GUI-specific dependencies.

[FWIW: I once tried SuSE Linux. It kept wanting to install a good
chunk of KDE because what were essentially command-line tools had been
built with optional (and mostly trivial) GUI features enabled. I
lasted around three days before ditching it for Gentoo.]

--
Glynn Clements <glynn@gclements.plus.com>

3

On Sun, Nov 28, 2010 at 09:29:28PM +0000, Glynn Clements wrote:

Hamish wrote:

> > > If the only available packages (RPM, .deb, etc) insist
> > > upon installing GUI libraries, complain to the people who
> > > make the packages.
>
> Paolo:
> > OK, so, now I'm complaining :wink: : packagers, please have
> > your saying here.
>
> disk space is very cheap. package maintaining time is not. IMHO
> unused libraries & a couple extra packages do no real harm

It isn't "a couple". Once you link against wx, you're looking at ~60
extra libraries.

I'd suggest that the core GRASS package shouldn't list X, wxWidgets or
(in 6.x) Python as dependencies.

It shouldn't be necessary to split the actual GRASS distribution into
GUI and non-GUI components. Put everything in the non-GUI package, and
have a separate GUI package which is empty (or contains a single dummy
file if the packaging system doesn't allow empty packages) and exists
solely to hold the GUI-specific dependencies.

As said in another mail of mine, it is not a problem brute-splitting GUI
dependencies (e.g. current squeeze release for 6.4 only *suggests*
wxpython dependencies). Moving GUI-related binaries in different
packages is a pain to maintain, but theoretically it can also be done.

It remains a brute hack anyway, which is a symptom of
a fundamental design problem: the whole system is theoretically
layered and modular, but in fact it cannot be really componentized
in a *clean* way. Something I find basically disturbing and not
elegant, sorry my purism.

BTW, I tend to disagree about considering GUI maintainance not influent
in the releasing cycle. It *is* influent and caused many of the
past/present windows/macos delays. Having a sort of grass-toolbox
and grass-gui sub-projects could help a lot (like CNES does
with OTB and Monteverdi).

And like it or not, there are people that do not use the
default GUI or a GUI at all. Splitting would gain consensus
about the core, which is IMVHO the true value of GRASS.

Of course, my 2 cents, as always.

--
Francesco P. Lovergine

4

Francesco P. Lovergine wrote:

As said in another mail of mine, it is not a problem brute-splitting GUI
dependencies (e.g. current squeeze release for 6.4 only *suggests*
wxpython dependencies). Moving GUI-related binaries in different
packages is a pain to maintain, but theoretically it can also be done.

It remains a brute hack anyway, which is a symptom of
a fundamental design problem: the whole system is theoretically
layered and modular, but in fact it cannot be really componentized
in a *clean* way. Something I find basically disturbing and not
elegant, sorry my purism.

You are really going to have to explain what you are talking about,
otherwise I (and possibly others) are going to conclude that you don't
have a clue and should just be ignored.

GRASS' structure is about as layered and modular as you can get. If
you install it on a system without GUI libraries, the only portions
which won't work are those which inherently cannot function without
those libraries (i.e. the GUI, digitiser, XDRIVER).

And like it or not, there are people that do not use the
default GUI or a GUI at all.

Like me. The only time I'll run the GUI is if I need to test some
aspect of the GUI. Which is why I have no idea where you're getting
these notions about integration from.

--
Glynn Clements <glynn@gclements.plus.com>

5

On Mon, Nov 29, 2010 at 10:20:52PM +0000, Glynn Clements wrote:

Francesco P. Lovergine wrote:

> As said in another mail of mine, it is not a problem brute-splitting GUI
> dependencies (e.g. current squeeze release for 6.4 only *suggests*
> wxpython dependencies). Moving GUI-related binaries in different
> packages is a pain to maintain, but theoretically it can also be done.
>
> It remains a brute hack anyway, which is a symptom of
> a fundamental design problem: the whole system is theoretically
> layered and modular, but in fact it cannot be really componentized
> in a *clean* way. Something I find basically disturbing and not
> elegant, sorry my purism.

You are really going to have to explain what you are talking about,
otherwise I (and possibly others) are going to conclude that you don't
have a clue and should just be ignored.

GRASS' structure is about as layered and modular as you can get. If
you install it on a system without GUI libraries, the only portions
which won't work are those which inherently cannot function without
those libraries (i.e. the GUI, digitiser, XDRIVER).

Something like:

make build-core | build-xdriver | build-wxgui | build-tkgui

make install-core | install-xdriver | install-wxgui | install-tkgui

would be more modular and clean. Of course, one can always now
install the whole beast, use only what is of interest and avoid
installing all dependencies. As said, it works too.
But I - as packager - would prefer avoiding tons of silly reports
about 'command X is not working because Y is missing' and installing
most required dependencies for all commands provided.

--
Francesco P. Lovergine

6

Francesco P. Lovergine wrote:

Something like:

make build-core | build-xdriver | build-wxgui | build-tkgui

make install-core | install-xdriver | install-wxgui | install-tkgui

would be more modular and clean. Of course, one can always now
install the whole beast, use only what is of interest and avoid
installing all dependencies. As said, it works too.
But I - as packager - would prefer avoiding tons of silly reports
about 'command X is not working because Y is missing' and installing
most required dependencies for all commands provided.

You can package it how you want, but I don't think that it's realistic
to structure GRASS around individual packagers' policies (e.g. who
says what is "core" and what isn't).

Every optional dependency can be disabled at configure time. At build
time, you can build individual directories. In 7.0, you can control
the target directory (ARCH_DISTDIR) separately from the directory
where previously built components are found (GISBASE).

Packaging involves work, and GRASS is no different to any other
package. E.g. most modern Linux distributions split libraries between
a run-time package containing the shared libraries and a -devel
package containing the headers, static libraries etc. The source tree
from which the package is built doesn't provide explicit support for
this; it's just something the packager has to do.

Moreover, integrating (and subsequently maintaining) the support for
various packaging systems would be significantly more work for the
GRASS developers than it would take for the package maintainers to
maintain their own packaging systems privately. A privately-maintained
system only needs to work to the level of "works for me". Something
intended for inclusion into the source tree has to be more "finished",
which can take more work than creating the original version.

--
Glynn Clements <glynn@gclements.plus.com>

7

MAKE system patches into studio! Be ready to deal also with any code
that migh assume GUI-related tools to be present by default.

Saving less than 10MB of uncompressed disk space is not worth a large effort.
GRASS has so many dependencies, that it's impossible to split-out all
tools that require some obscure lib/utility without ruining GRASS as
whole. I doubt that Debian now is providing ALL dependencies of ALL
GRASS modules - reports about "module X requires Y" will not go away
because of GUI/CLI split.

As GRASS lacks manpower - code or GTFO* :wink:
Maris.

* A nice reference to Chatroulette

2010/11/30, Francesco P. Lovergine <frankie@debian.org>:

Something like:

make build-core | build-xdriver | build-wxgui | build-tkgui

make install-core | install-xdriver | install-wxgui | install-tkgui

would be more modular and clean. Of course, one can always now
install the whole beast, use only what is of interest and avoid
installing all dependencies. As said, it works too.
But I - as packager - would prefer avoiding tons of silly reports
about 'command X is not working because Y is missing' and installing
most required dependencies for all commands provided.

8

On Tue, Nov 30, 2010 at 4:12 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Francesco P. Lovergine wrote:

Something like:

make build-core | build-xdriver | build-wxgui | build-tkgui

make install-core | install-xdriver | install-wxgui | install-tkgui

would be more modular and clean. Of course, one can always now
install the whole beast, use only what is of interest and avoid
installing all dependencies. As said, it works too.
But I - as packager - would prefer avoiding tons of silly reports
about 'command X is not working because Y is missing' and installing
most required dependencies for all commands provided.

You can package it how you want, but I don't think that it's realistic
to structure GRASS around individual packagers' policies (e.g. who
says what is "core" and what isn't).

Well, I think that Francesco suggestion above is pretty clear.
It does not look like too strange to me and sufficiently generic.

Markus

9

make build-core | build-xdriver | build-wxgui | build-tkgui

make install-core | install-xdriver | install-wxgui | install-tkgui

as far as the debian grass package goes, perhaps we could have
a main "grass" package, which depended on "grass-base" and
"grass-gui" packages. The -base package wouldn't depend on the
-gui package, so folks who didn't want the GUI deps could avoid it.
also "apt-get install grass" would still install what people
expect: base+gui.

not sure if -base or -core is preferred, but whichever..

Hamish