Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Popularity, visibility, and level of involvement

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Popularity, visibility, and level of involvement
  • Date: Mon, 5 Oct 2015 22:46:47 +0200

Am Sat, 3 Oct 2015 04:18:29 -0500
schrieb Jeremy Blosser <jblosser-smgl AT firinn.org>:

> On Sep 29, Ismael Luceno [ismael.luceno AT gmail.com] wrote:

> > Also, although less important, most are unhappy about having to
> > configure every minute detail the first time (this is something we
> > could easily solve, without compromising our goals),
>
> I don't see how, given how integral "we promise to install upstream
> defauts, unless you tell us otherwise" is to who we are. It's nearly the
> entire point.

I want to hook in here: I dream of a SMGL install/rebuild/update that I
can start and actually expect it to finish unattended. I don't want
things to be carefully tuned and preconfigured, all I want is that I'm
not _forced_ to reconfigure everything to have a working system at all.

I think it should be a valid way to do a SMGL install to do it with
PROMPT_DELAY=0. and only `cast -r` stuff that one cares about. Of
course, part of this is handling of cyclic dependencies. A global
setting of "all optional dependencies off by default" also might make
sense (I admit that I know that the sorcery defaults mechanism is
there, but I'm not totally sure how far it reaches).

I think it is great that I get the options offered in a cast and don't
have to look up things, but at the same time, it is frustrating to have
to abort a cast after 100 answered questions and start again because
one realized that the last answer was not good (pulling in lots of
unwanted deps suddenly, p.ex.). This would be alleviated if we finally
had a declarative configuration system with nonlinear answering à la
kernel or busybox menuconfig.

These technical questions, discussed at length many years ago already,
are the points where I really would like SMGL to move forward … I
didn't mention proper staged casting (of multiple spells, atomic merge
to filesystem) yet, did I?


Alrighty then,

Thomas

Attachment: pgpvrdrMhPa0e.pgp
Description: Digitale Signatur von OpenPGP




Archive powered by MHonArc 2.6.24.

Top of Page