Skip to Content.
Sympa Menu

sm-grimoire - Re: [SM-Grimoire]Auto rebuilding dependent spells

sm-grimoire AT lists.ibiblio.org

Subject: Discussion of Spells and Grimoire items

List archive

Chronological Thread  
  • From: "Chris Brien" <christopher_brien AT hotmail.com>
  • To: dufflebunk AT dufflebunk.homeip.net, charkins AT upl.cs.wisc.edu
  • Cc: sergeyli AT pisem.net, sm-grimoire AT lists.ibiblio.org
  • Subject: Re: [SM-Grimoire]Auto rebuilding dependent spells
  • Date: Mon, 05 Aug 2002 23:01:59 +0100

From: Dufflebunk <dufflebunk AT dufflebunk.homeip.net>
Most dependants don't need to be rebuilt. They either run a binary
that
the the dependee creates, or use a shared lib that the dependee creates.
Only when a program staticly copmiles in a library provided by another
spell does it have to be recompiled when the other is updated (so it'll
be able to compile in the new library).

Exactly - only statically linked programs need to be rebuilt. Usually...

When a library is upgraded, dependencies can no longer be dynamically linked, but cast --fix takes care of that (which is ran automatically by sorcery update).

Then there are other cases where a configure stage makes assumptions that are no longer true when a dependency is updgraded.

That said, the kernel is an exception. Many spells put things in
/lib/modules/*, and when a kernel is recast, they dissapear (at least
this is my experience). There are good reasons to remove modules when a
kernel is modified.

Such as: using a kernel module built for another kernel is A Bad Idea.

However, I agree that there should be a triggering
mechanism so that a spell can recast itself is another spell is recast.

I agree - there should be more options for dependencies. It's not enough to just say "install this other spell before this one", there are other relationships such as "rebuild me whenever this other spell is rebuilt" and "i need this other spell only when compiling and don't need it for operation". There are others I can't think of right now, but the relationships between spells need to be more clearly defined.

The first (simplistic) dependency is already available. The second type (triggering a rebuild) would take care of the kernel stuff as well as Linux-PAM and anything else that wants to. The third type would be used for stuff like autoconf and obscure compilers that aren't needed for runtime.

The new "linux" spell has a list of spells that are rebuilt afterwards if installed - all those listed by casey are there, and adding NVIDIA_nforce would be trivial - but it would make more sense to have the dependee worry about when it needs to be rebuilt than the dependency.

Chris
aka zero_the_hero


On Mon, 2002-08-05 at 17:11, Casey Harkins wrote:
> Ahh, I see now.
>
> Most or all of the non-kernel flavor spells in the kernels section should
> probably be added to the end of the POST_INSTALL for the various kernel
> spells: 3c990, e100, hcflinmodem, i2c, lm_sensors and ltmodem. cvsfs is
> already there, and the NVIDIA_nforce spell I submitted to bugzilla will
> also need to be added if accepted.
>
> There has to be a better way to do this! Shouldn't we rebuild all
> dependent spells?


_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com





Archive powered by MHonArc 2.6.24.

Top of Page