Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] What's going on with cast?

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] What's going on with cast?
  • Date: Tue, 29 Jun 2004 18:26:21 -0700

>
> However, that doesn't seem to affect some spells. For example, right
> now, I'm re-casting gimp-print to fix up the first error listed there.
>
> I can't say that I'd run "cleanse --prune doit" before now (but have run
> cleanse by itself twice) since upgrading to the latest stable sorcery.
>
> As an aside, why is cast lying about dropping depends? It doesn't
> appear to be doing a bloody thing when it brings up those errors.

Cast isn't "lying" about dropping depends. With the sorcery 1.10 series
and devel for many months prior we've put in a full dependency ordering
feature. The way this works is that we take all the spells that are
installed or going to be installed and figure out what spells they depend
on (either ones that are already installed, or are going to be installed)
then like before it creates a big whopping makefile to hold all of it.
Then cast tells make to build the spells you asked for using the information
in the makefile. This results in spells being cast in their proper
order, so if gnome libraries and gnome apps update at the same time,
the gnome app wont upgrade until after the dependant gnome libraries
update. Otherwise you're stuck in this horrible state where your apps
are compiled against already upgraded libraries, or worse, they wont
compile against the old libraries and they fail for no reason.

Theres two errors that make can spew, one is that theres a circular
dependency, you cant do anything about that, and the only thing the
sorcery team can do is re-work that part of cast to not use make. While
I want to do that someday its a pretty big undertaking, so I haven't
yet. So basically dont worry about those ones, theres nothing we can do.
Its also pretty harmless in that make is just admiting that theres a
circular dependency and will still make both targets, but just not get
stuck in some infinite loop. In a perfect world the dependency tree would
be a DAG, but its not.

The other problem is "dropped dependencies", this is caused by a hole in
your depends tree. So spell A depends on B and B is missing from the tree
(its not installed). This is mostly what the prune phase of cleanse is
interested in, and what is the only known and quantified way in which
"cast" (make) will bail out. Make does not like the fact that in order
for you to make A, you need B and there isn't a way to make B...make
is annoying this way.

As far as your issues with cleanse not living up to its name, what other
option would you like? How else would you fix a dependency? I suppose if
the dependency was optional we could change it to be off, but in terms
of something thats absolutly required what other choice do we have?
Delete it? Thats only legal if the spell no longer depends on B, and
its not easy to determine that short of recasting the spell, which in
your case you did, and you might want to recast some stuff to avoid
upgrade issues. Of course if the dependency no longer exists the spell
should be up for upgrading...

I sympathize with how annoying this, but please realize that our
dependency system is not a simple thing. I dont know of another
distribution that offers as much flexibility as our system does. Binary
distros have a hard wired, static depends tree, so they can never get
into this problem (nevermind that its hard to have a binary package
fail to install). Neither gentoo nor freebsd's ports (to my knowledge)
offer the same degree of control we do either, they seem to just vaguely
touch on the notion of "optional" dependency. We've also made mistakes in
the past and cast has been rather poor at cleaning up state files after
itself, so theres quite a few rough edges Im doing my best to sand down.
Please bare with us...

Thanks
Andrew




Archive powered by MHonArc 2.6.24.

Top of Page