sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] Popularity, visibility, and level of involvement
- 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
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Ismael Luceno, 10/01/2015
- <Possible follow-up(s)>
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/03/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Thomas Orgis, 10/05/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Sukneet Basuta, 10/05/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Ismael Luceno, 10/07/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Kevin Monceaux, 10/07/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Thomas Orgis, 10/05/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/03/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/03/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/08/2015
- Re: [SM-Discuss] Popularity, visibility, and level of involvement, Jeremy Blosser, 10/08/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/08/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Jeremy Blosser, 10/07/2015
-
Re: [SM-Discuss] Popularity, visibility, and level of involvement,
Vlad Glagolev, 10/07/2015
Archive powered by MHonArc 2.6.24.