Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] devel-xorg-modular security fixes

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Javier Vasquez <j.e.vasquez.v AT gmail.com>
  • To: Remko van der Vossen <wich AT yuugen.jp>
  • Cc: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] devel-xorg-modular security fixes
  • Date: Mon, 2 Dec 2013 00:57:09 -0600

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.




Archive powered by MHonArc 2.6.24.

Top of Page