Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] feature creep. WAS: splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Kolb <jkolb AT brandeis.edu>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Mon, 09 Oct 2006 08:41:13 -0400

Juuso Alasuutari wrote:
> On Monday 09 October 2006 14:36, Jens Laas wrote:
>> Hello!
>>
>> I fear feature creep and increased complexity in SMGL.
>>
>> To start with I appreciate all the good work you developers (and others!)
>> do for SMGL.
>>
>> But my main attraction to SMGL was the ease for the admin to casually view
>> and _understand_ the spells. Increasingly functionality has moved out of
>> the spells and into library functions, thus decreasing understandability.
>>
>> Its easier to fix something simple when it breaks than fixing something
>> complex. And things do inevitably break.
>>
>> So, in short, simplicity is a virtue. Atleast for me.
>>
>> Thanks again for your outstanding work!
>> Cheers,
>> Jens
>
> Disclaimer: I'm not a Sorcery developer, nor an expert in computer science,
> so
> take what I say with a grain of salt. Hopefully someone more experienced
> will
> correct me if I'm wrong about something.
>
> <reply>
>
> It seems to be an unfortunate law of computing that a program which
> operates
> within a complex environment will by necessity run into situations for
> which
> there are no simple solutions. And the longer it operates, the more it
> gathers these experiences.
>
> Sorcery has to tackle issues that many other package managers can remain
> blissfully aware of. We have a very advanced and, because of that, a very
> complex dependency resolution framework whose existence is partially
> dictated
> by the fact that we compile from sources. Oh, how easy it would be to just
> distribute binaries... But fortunately that's not what we're here for. :)
>
> During our existence we've run into a wide array of problems, leading to
> the
> added features you're concerned about. It also concerns me that spell
> writing
> might get too complicated and spell maintenance too stressful. But I also
> trust that none of us want that (one example being the decision to not
> implement versioned dependencies).
>
> Luckily, there is also progress being made in the right direction. When the
> smgl-filesystem (castfs) work is finished and we finally have a proper way
> to
> do staged installs, we can wave good-bye to $INSTALL_ROOT and $TRACK_ROOT
> in
> spells. I hope the future will bring more such positive changes.
>
> I hope you could give some concrete examples where you see unnecessary
> and/or
> stressful complexity in a spell. We could ponder if something could be done
> more intuitively, or if that might lead this discussion to even more
> fertile
> grounds.
>
> </reply>
>
> <suggestion>
>
> As I said I'm also concerned about complexity. And recently I've paid
> attention to how updating libraries will cause breakage here and there, and
> how stressful it is to hunt for dependees that break because of it.
>
> When a new program version comes out that changes foo.so.1 to foo.so.2, all
> hell breaks loose in every spell that depends on it. For that we need to
> add
> a check_self in everything that directly links against foo.so. But it
> doesn't
> necessary have to be like that.
>
> First of all, let me just state the obvious: Less specific, more general
> solutions that catch more errors are slower. Less work by hand equals more
> work by the CPU. So this is the tradeoff here.
>
> What I've had in mind is an option (if not the default action) to run a lib
> check on _every_ first-level dependee after a spell is recast. So, if bar
> and
> qux depend on foo, then every time that foo is recast, bar and qux are
> checked for lib breakage immediately afterwards.
>
> This would make casting somewhat slower, but personally I'd happily pay the
> price for not having to do so many full-house cleanses and hunting for
> missing check_self triggers.
>
> </suggestion>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss

I say fix sorcery system-update first. It takes 15 minutes to figure
out what spells need updating after downloading the latest grimoires.

Jeremy




Archive powered by MHonArc 2.6.24.

Top of Page