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

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Daniel" == Daniel Skarda <0rfelyus@ucw.cz> writes:

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

I agree; I've been thinking about some of my own guile packages that I
have been keeping separate (from each other) and came to the same
conclusion: it's a pain for me because of the overhead of working out
dependencies and the best place for everything, and it puts barriers
in the way of someone coming across something interesting just because
it is there.  With their xxx-pers-scheme distributions, ttn and
mgrabmue have had this right all along.
   
    Daniel>   Do you think that Mr Joe A. Programmer will choose Guile
    Daniel> because Scheme is superior language and "Official GNU blah
    Daniel> blah blah"?

Yes I do, but that doesn't mean we have to make other aspects of the
experience hard.

    Daniel>  * Read "guile-debugger" thread on guile-devel. Even
    Daniel>  developers have not known that there is guile-debugger
    Daniel>  package.

In this case, though, the package is still new and possibly not ready
for the core.

    Daniel>   So these were my arguments I could think of. Please try
    Daniel> to write down your oppinions.

Here are the opposing arguments that I can think of.

- As Rob says, life gets tricky if the distro as a whole has more
  external dependencies - e.g. gtk, xlib, postgres, librx.  Building
  from source is OK: just allow and handle a corresponding --with-xxx
  flag to ./configure for each dependency.  But distributors will want
  to build different pieces with different dependencies:

  - the "core" piece, with no additional dependencies

  - the gtk add-on piece, which depends on the core and on Gtk

  etc.  Note that, if this logic is correct, distribution package
  users will always end up seeing lots of small packages, even if
  coming from a single Guile distribution.

  It might be fun to have a flexible build that allowed to build all
  these pieces from a single distribution, but (i) would we just be
  reinventing the wheel known normally as packages, and (ii) is it
  worth it just for the ./configure && makers?

  Or we could agree only to bundle stuff that does not introduce any
  new dependencies.

- Download size.  (Although, globally, this is reduced, by not
  multiplying copies of COPYING, ltmain.sh, texinfo.tex etc.)




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel