Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] SourceMage Binary Grimoire Proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Casey Harkins <charkins AT upl.cs.wisc.edu>
  • To: Dufflebunk <dufflebunk AT go-nix.ca>
  • Cc: Source Mage Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] SourceMage Binary Grimoire Proposal
  • Date: Sun, 3 Aug 2003 20:50:38 -0500 (CDT)



On Sun, 3 Aug 2003, Dufflebunk wrote:

> A slightly related topic is that of binary packages for smgl. I am against
> this, not for any practical reason though, but for the philisophical reason
> that smgl is a source distro. It's designed as such, and although extending
> to handle binary packages is quite possible, it would never be as good as
> the current offerings in the binary world. Just as no mater how hard binary
> distros try, they are unable to make as good source based packages as soucr
> based distros have.

I agree completely that smgl shouldn't have a general binary packaging
system. Unfortunately, using a pure source based solution in my case would
be a nightmare. Most of our computers are between 200 and 2000 miles away
from me. One bad compile could mean a lot of driving and/or fedexing, not
to mention many sleepless nights.

However, I philosophically agree with the ideals of a source based
distribution and want the benefits of finer configuration and more up to
date packages (not to mention a system that isn't bloated with unnecessary
software).

With my approach, I get most of the benefit of the source based
distribution, yet make the system as a whole a little more fault tolerant.


> In cast, after the dependencies are checked, a check for the cached tarball
> is made. If this exists, the spell will be resurected, UNLESS -r or -c are
> specified (or a couple of other cases that force those switches).
>
> So if you have a global cache, cast will assume that the dependancies you
> chose are those for the tarball in the cache. You are correct that the
> depends info isn't stored in the cache. To do so would server little purpose
> (until people want to do what you want to do ;), would slow down the
> dependancy checking substantialy, or would increase the complexity of the
> dependancy checking stuff a fair amount (something no one wants as few
> enough people as it is understand that section of code).

Since cast is assuming that the dependencies are the same as the tarball
in the cache, couldn't the cache just store its dependencies in the cache.
This way resurrecting could restore those to the depends info. dispel
would also need to be modified to remove the depends info from
/var/state/sorcery/depends. As it sits right now, 'gaze depends' can have
incorrect results if you've dispelled something that had dependencies.

> I believe that just a week or two ago someone posted a simple util for
> giving a LAN http access to your (source) cache. Using that and a slightly
> modified sorcery you could try to grab the compiled cache from the server
> running that util. It should only be necessary to add a line or two to cast.

I saw that, pretty nifty actually!

I've decided to stick with my local binary grimoire solution. If at some
point I decide that I can trust the client machines to build their own
packages, I can simply switch grimoires. The spell names remain the same,
all dependency info should be intact. A simple 'scribe add stable; scribe
remove mybingrim; sorcery rebuild' should turn it back into a standard
SMGL source based installation.

I appreciate everyone's input!

-casey






Archive powered by MHonArc 2.6.24.

Top of Page