sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] devel-xorg-modular security fixes
- From: Sukneet Basuta <sukneet AT gmail.com>
- To: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] devel-xorg-modular security fixes
- Date: Tue, 03 Dec 2013 09:36:19 -0500
On 02/12/13 01:57 AM, Javier Vasquez wrote:
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...
Hmm, thinking about it, this may be a viable option by chaining commands. I don't have the time to work on this currently though. If someone else wants to step in (I already made a pretty good list of spells above), please do. :)
-
Re: [SM-Discuss] devel-xorg-modular security fixes,
Javier Vasquez, 12/02/2013
-
Re: [SM-Discuss] devel-xorg-modular security fixes,
Sukneet Basuta, 12/03/2013
- Re: [SM-Discuss] devel-xorg-modular security fixes, Javier Vasquez, 12/14/2013
-
Re: [SM-Discuss] devel-xorg-modular security fixes,
Sukneet Basuta, 12/03/2013
Archive powered by MHonArc 2.6.24.