Public SourceMage Discussion List

[Sukneet Basuta <sukneet AT gmail.com>]

On Tue, Aug 26, 2014 at 5:54 PM, Thomas Orgis <thomas-forum AT orgis.org> wrote:

Am Tue, 26 Aug 2014 10:25:26 -0400
schrieb Sukneet Basuta <sukneet AT gmail.com>:

> I think we are all in agreement here, but, unless we abandon the idea of a
> clean upgrade path, I don't see it happening anytime soon.

I think that ship has sailed long ago. I _never_ had a clean Source
Mage install in about 8 years now. There is always something broken
that needs manual care. We had times where the project was much more
vital and even then there was always something broken. We should
document the issues one needs to fix up manually and get going.

Agreed, I've never had a clean Source Mage install, but I've never actually used the stable grimoire. IIRC, last time we had the discussion of merging devel-xorg on the mailing list, people were still concerned about this.

Actually, I must admit I'm not sure anymore of what specific upgrade
blockers you are talking. I must have hit them somehow during the
journey from an install from the old x86-64 ISO to devel-xorg grimoire.
There was so much to fix ... what was the specific issue of upgrading
xorg?

I tried to make a master bug http://sourcemage.org/issues/423 , but no one else seemed to contribute to it.

Unless you cast a bunch of X11 spells before switching to devel-xorg, you wouldn't have run into the main problem. The major issue is that a bunch of spells link to libpthread-stubs which need to be recast when moving to devel-xorg, since there is a ABI incompatible update of libpthread-stubs. I've tried to resolve this, but I couldn't find a good way to do it without getting lots of circular dependencies and such. I think Remko's idea is the best solution to this problem:

On Sat, Nov 9, 2013 at 12:41 PM, Remko van der Vossen <wich AT yuugen.jp> wrote:

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.

Honestly, I'd love to get around to implementing this, but I don't have the time currently.