Public SourceMage Discussion List

[Andrew <afrayedknot AT thefrayedknot.armory.com>]

On Thu, Mar 03, 2005 at 01:21:19PM -0800, David Braaten wrote:
> I have a severe problem with the way sorcery rebuild
> works.
> I did a 'cast -c gcc g++ && sorcery rebuild' on
> Tuesday, and let it go.
> Today, it still wasn't finished rebuilding, and it
> hadn't even built glibc.
> I'm attaching what was in the queue/install and the
> section of the activity log.
> 
> I expected sorcery rebuild to build the system
> starting at the bottom of the dependency tree (ie:
> coreutils then glibc then db ) 
> (using sorcery test 1.11.5-rc1)
> Instead, what appears to have happened, is that it
> queued up everything in whichever order it found them,
> and then the TRIGGERS caused a lot of rebuilding of
> qt-x11 and kde (which takes hours each time).
> 
> I propose that:
> 1) sorcery rebuild should do some reasonable
> dependency sorting so that spells at the bottom of the
> tree are built first.

It does, and it has for almost a year now. The more likely problem is that
your dependency tree is either missing or very incomplete. Almost the exact
same problem came up a week or so ago...

Full dependency ordering has been a feature for quite some time but sorcery
isn't an AI, if you dont have a dependency tree at all or its incredibly
sparse than sorcery cannot figure out the dependencies because theres nothing
to derive them from.  In the lack of dependency information sorcery
(make actually) will degrade to building things in the order it found
them, in the presence of a sufficiently small depends tree it'll 'mostly'
build things in the order it found them, again, nothing we can do without
proper depends info. Sorry.

The only possible solution I can think of to ensure that on rebuild
basesystem spells are cast first (even if the user for some reason
removes their depends tree) is to have sorcery assume and enforce that
everything depends on basesystem.

> 2) during sorcery rebuild, TRIGGERS should NOT be
> executed.
> 

Globally disabling triggers would probably cause other unforseen
problems. IMO triggers are /way/ overused, ive seen a lot of uses for
them that arent needed, but theres some uses for them that are genuinely
valid, but theres no way to tell the difference now is there? That aside
however, in order to really solve the problem rather than pretend its not
there, depends and triggers need to be combined. But thats not exactly
a trivial problem to solve given that some triggers can stand to wait,
and others cant, and again, no way to really know the difference.

-Andrew