Public SourceMage Discussion List

[Javier Vasquez <j.e.vasquez.v AT gmail.com>]

On Sat, Nov 9, 2013 at 11:41 AM, Remko van der Vossen <wich AT yuugen.jp> wrote:
> On 2013/11/09, at 5:29, Sukneet Basuta <sukneet AT gmail.com> wrote:
>> I haven't had the the time to work on this in over 2 months, so I'm giving 
>> up on it. I've attached a git patch that adds a bunch of spells to 
>> libpthread-stubs' UP_TRIGGERS that should get a working system at least. 
>> However, the problem is that I can't get the spells to cast in the correct 
>> order (adding dependencies ends up with cyclical dependencies). So you 
>> have to keep recasting libpthread-stubs until everything compiles okay. 
>> This is not a proper upgrade path imo, but I couldn't think of anything 
>> better given the current limitations of Sorcery.
>>
>> This isn't a complete list either since I gave up adding spells to it 
>> after a bit and instead focused on trying to get spells to cast in the 
>> correct order. If the leads decide to merge this, I'll try to eventually 
>> compile a complete list of spells that need recasting.
>
> Yes, I think this is the biggest problem we have in Source Mage. libpng 
> suffers from exactly the same problem, as did the libxcb upgrade we 
> suffered through some years back. The unnecessary deep linking that is done 
> by libtool only exacerbates the problem, hence my suggestion to move 
> forward on --as-needed a while back. But that will only improve matters, it 
> will not completely solve them.
>
> I think the only proper way to solve this is to have sorcery collect the 
> link dependencies from the installed spells, in the case of ELF dynamic 
> objects, the spells that provide each of the listed DT_NEEDED entries in 
> the dynamic objects, even if the listed entry is not directly used, as 
> building anything that links to that object will fail if the dynamic object 
> in the entry does not exist anymore. Then, when casting anything, sorcery 
> needs to know about incompatible upgrades, build a tree of link dependent 
> spells ignoring dependencies in DEPENDS for this tree, and immediately cast 
> those spells in the correct order. We still have to see about resolving any 
> cyclic dependencies if there are any, and it should be seen whether these 
> spells should be cast from the grimoire or from tablet. Then and only then 
> should sorcery continue casting its normal queue, meaning that the link 
> dependency triggered queue should be separate from the normal cast/install 
> queue.
>
> This would of course mean a big change in sorcery though and given the lack 
> of time and motivation for any big sorcery work, I don't think this is 
> going to happen anytime soon.
>
> Regards, Remko


Can a planar list of casts (no matter if some get repeated) be created
so that at the end all dependencies issues get solved by casting spell
by spell, one at a time?  If so, perhaps documenting such list of
steps might be a work around...


-- 
Javier.