Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Circular dependencies between spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: David Kowis <dkowis AT shlrm.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Circular dependencies between spells
  • Date: Mon, 25 Aug 2008 15:47:18 -0500

Andraž 'ruskie' Levstik wrote:
On 17:07:48 2008-08-25 Fredrik Carlström <fredrik.carlstrom AT tele2.se>
wrote:
Hi

I've noticed some problems with circular dependencies between spells in sorcery. For example casting pkgconfig and enabling the optional dependency on glib2, will fail if pkgconfig isn't already installed. This is because pkgconfig is a build time requirement for glib2, but sorcery will try to install glib2 before pkgconfig. Is this a bug, or isn't resolution of circular dependencies implemented in sorcery?

If the latter is the case, this is a sketch of a simple and perhaps possible solution. Observe that I'm not familiar with how this is currently done in sorcery, so this might be easy, hard or even impossible to implement. There might be problems and that I'm not aware of. Perhaps someone more familiar with sorcery than I, could take a
look at this and see if it's at all possible to do.

First, unconditional circular dependencies between packages (as for example between tetex and tetex-texmf) would have to be resolved. The only way this can happen (outside the tool chain) is if at least one is a runtime dependency of the other. These must be labeled as such. To
get this solution to work, it is only needed in those rare cases where
there are an explicit unconditional circular dependence between
packages.

We get:
runtime_depends Must be installed before or after this package.
depends Must be installed before this package is built.
optional_depends Must be installed before configuring and building with this support.

While collecting spells for installation, runtime dependencies can be treated as before. There will be no essential difference in the collection of spells to cast. While casting spells, runtime
dependencies can be ignored.

The part that must be reimplemented is the casting of queued spells. This can be done in two functions:

The first function will loop through the queue repeatedly and install spells that have all build time dependencies fulfilled, until the queue is empty.

function install(queue) {
while the install queue is nonempty {
for pkg in queue {
if all build time dependencies are fulfilled
cast pkg # and remove from the queue
dequeued=true
}
if not dequeued then forced_install(queue) # If there is a circular blocking optional dependency
}
}

The second function forces an installation if there is a circular blocking optional dependency

function forced_install(queue) {
search the queue after a package pkg with all unconditional dependencies fulfilled,
and as few optional dependencies as possible that are not installed
cast pkg # without the optional_depends from spells that are not currently installed, but do NOT remove from the queue
}

Somewhere in this, self triggers and logging etc must be checked and done as well. This is so that all the intricate internals of spell casting are fulfilled.

If this could be implemented, the example with pkgconfig and glib2
would be solved as follows:
First install(queue) will try to install glib2 and pkgconfig, but fail miserably with both due to a circular dependency. Then forced_install will cast pkgconfig without the optional support for glib2. After that glib2 can be casted, and at last pkgconfig will be reinstalled with support for glib2.


This can easily be bypassed in the spells themselves...

if spell_installed glib2 ; then optional_depends glib2
fi


Anyone else get that 4 time also?


--
David Kowis

www.ronpaul2008.com - Ron Paul for President!
www.sourcemage.org - SourceMage GNU/Linux

Attachment: signature.asc
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page