Module component list updated [was Re: Modularization development notes]

[Kevin E Martin]

On Wed, Apr 20, 2005 at 10:48:57AM -0700, Alan Coopersmith wrote:
> Are we going to break every single app out into a separate module/package
> or do we want a logical grouping?

I'd prefer to see the apps be broken out into separate packages instead
of putting them into a hierarchy or logical groupings.  The main reason
for this is that some vendors will want to ship a subset of packages,
and we should not make it more difficult for them by pre-determining
groupings.  It also makes it difficult to separate packages that are
part of an official X.Org release from those that are not (once we open
up the modular tree for new code).

>                                     We've already discussed this with Xpm
> & fontconfig, bundling those apps into their libraries.

I think these fit into a different category.  Utilities, config tools,
examples or support programs for libraries should be fine to include
with the associated library component.

> Other possible "logical groupings" I see in the list:
> 
> ICE: lib/ICE & programs/iceauth
> SM: lib/SM, programs/xsm & programs/smproxy
> Xv: lib/Xv & programs/xvinfo
> Xcursor: lib/Xcursor & programs/xcursorgen
> XKB-clients: xkbevd, xkbprint, xkbutils, setxkbmap
> XKB-core: libxkbfile, xkbcomp (since they're both client & server)
> Xt-resource-clients: appres, editres, listres, viewres
> Xprint-clients: programs/xphelloworld, xplsprinters, xprehashprinterlist
> DPS: lib/dps, lib/dpstk, dpsexec, dpsinfo, texteroids, makepsres
> X-input-clients: xsetmode, xsetpointer
> X-core-fonts: lib/font, mkfontdir, mkfontscale, bdftopcf

I think it would be fine to put these in with their associated
libraries.

> demos/samples: xgc, xdbedizzy

xgc could be included with lib/X11 and xdbedizzy could be included with
Xext.

> X-core-clients: xhost, xauth, xdpyinfo, xset, xwininfo, xlsatoms, 
> xlsclients,
> 	xprop, xmodmap
> 	(xdpyinfo is probably most commonly updated to add new extensions
> 	 that it's useful to report specific details of, so could possibly
> 	 be separate)
> xwd: xwd, xwud, xpr
> xfs-clients: xfsinfo, fslsfonts, fstobdf, showfont
> X-core-font-clients: xfd, xfontsel, xlsfonts
> x-proxy: xfwp, proxymgr, xfindproxy (should probably document xfwp as
> 	deprecated in favor of ssh with X forwarding, but I believe
> 	the others work with lbxproxy and other proxies as well)

Most of these I think are standalone apps and utilities, and I think
should remain separate.

> clients that should go away: xmh  (does anyone still use this?  it's been
>  years since I used mh, but even then everyone I knew had switched to exmh
>  for GUI and nmh for command line)

I have no problem with deprecating xmh.  There are probably others that
could be deprecated as well.

> I suppose the question here is how useful is it to keep these separate or
> are they only likely to be wanted as a group?   And of course, do these
> groupings end up in a dependency graph that's a tree, with no loops or
> other complications?

I'm concerned that it's unlikely to make logical groupings or a logical
directory hierarchy that could work for everyone.  Leaving the app
module flat makes it easy for vendors to make their own groupings and
allows us to determine which components are included in our official
releases.

Kevin