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: Juuso Alasuutari <iuso AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Mon, 9 Oct 2006 15:23:48 +0300

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>

--
Juuso Alasuutari
[[ Source Mage GNU/Linux ]]

Attachment: pgp4QmIl4OnBS.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page