Re: Adding stuff to the core distro (was Re: Infix syntax)

[Rob Browning]

Daniel Skarda <address@hidden> writes:

>   I my opinion, breaking guile into small (orthogonal) packages is
> nice from "pure" developer's view, but it fails in "real world" and
> builds unnecessary walls between Guile and Joe Average Programmer,
> who wants to evaluate Guile:

I wouldn't propose that we break guile up into a "maze of twisty
packages", but I do think that long-term, maintaining some divisions
may make sense.  I'm not even sure we necessarily need to do anything
wrt to guile-core as it stands -- for the most part, I'm interested in
what we might do going forward.

IMO whether or not we break up the *source-tree* is a different
question from what we do at install time, and what policies we adopt
wrt interdependencies inside and outside guile-core.  For example, we
might decide to have a very large source tree that by default installs
everything, but can also just install parts of itself.  Maybe

  make install-core
  make install-srfis
  make install-gtk

or whatever, if we went the "big tree" route.

Two parties I'd like to keep in mind when making these decisions:

  - the packagers - we should consider what happens if I want to
    package guile for debian and we've stuck guile-gtk, qt, kde,
    gnome, etc. all in the main tree.  If I build and install with
    everything, I can assure you there will be a *lot* of users who
    will (legitimately) complain that I'm forcing them to install, say
    X, gtk, qt, and gnome on their *non-X* system.  There are a
    variety of ways we could handle this, but I think it's important
    to keep in mind.

    (This has actually been a fairly major hassle to fix in the
    current emacs21 wrt x and no-x, and I'm still not finished.)

  - the special cases -- we should consider what effect any
    arrangement we discuss might have on the difficulty of using guile
    in small environments.  i.e. the user (or distribution) who wants
    to put guile on a firewall, ipaq, or mini-board.  If we only
    support a make install of 20MB+, then we're not considering this
    case, and IMO it's not very workable to just say "these people
    need to pick out the bits they need themselves" -- if we don't
    have some policies wrt to our "core", then we'll eventually end up
    with all kinds of cross-dependencies between different modules.

    As an example of a policy question -- if we added a perlre module,
    would it be OK for the core code to use it?  How about srfi-1?,
    etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD