Bugs for Sorcery are reported here

[bugzilla-daemon AT metalab.unc.edu]

http://bugs.sourcemage.org/show_bug.cgi?id=7184

acedit AT armory.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Defective Dispel            |Defects in Dispel



------- Additional Comments From acedit AT armory.com  2004-07-28 12:20 -------
Dispel also should deal more gracefully with files that are modified
or owned by other spells.

Having an installed grimoire and having spells list special files they
want excluded can help alleviate the situation we currently have where
we have to manually add things to the master excluded list. That is, if
we want to continue with the same excluded mechanism where files are not
tracked at all.

As for dependencys, I'll brainstorm a little, dispel can go both up
and down the tree, down the tree, would be dispelling newly created
orphans up the tree would be fixing/dispelling parents
compute_installed_depends will build a hash table of the dependency tree
linked downwards, I have another, very similar routine that builds the hash
linked upwards. Using these in conjunction can make either up or down
resolution relatively painless.

Orphan detection could work as follows:
for child in $(hash_get depends_down $spell); do
  if hash_get depends_up $child | grep -q -e "^$spell$"; then
    if query "$child is an orphan, put it out of its misery?"; then
       <add $child to a dispel queue>
       modify in memory depends tree
    fi
  fi
done

Parent fixing is a little trickier, but works on the same general principle,
for parent in hash_get depends_up $spell, then do something. However doing
this a lot is going to get tricky as some spells may get recast several times
if significant turmoil is created in the tree. At which point I think it would
be better not to solve that entire problem in dispel and leave it to cleanse.

As a side note: currently dispel removes old dependency information
about the current spell. This information might serve well to be put
in the abandoned pool and used later by un-written libdepends enhancements.

I've also split dispel up in my sandbox into a frontend + library. Reason
being that in preparation for doing this, theres no reason to recursively
call the dispel tool, rather just call a function in the same environment.
I'll submit all this once I have the last few install_root issues taken fixed.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.