Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

Quoting 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.

Should we file a bug for this so we don't forget?

> > 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.

The reason TRIGGERS are overused (IMO) is that we try to cover the case when a
library/dependency is updated and the dependees need to be recompiled to find
the new library (openssl updates, glibc updates, gcc updates, etc.), but we
can't really tell if the version changed enough to warrant that (usually a.b.c
to a.c.d would need it but a.b.c to a.b.e would not). So we cover some cases 
of
this, but not all. It's really sporadic on what we cover for this as it's not
quite the proper "fix", but it'll ensure that a system works afterwards (for
the packages that have the extra TRIGGERS).

-sandalle

--
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.