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: "Dufflebunk" <dufflebunk AT go-nix.ca>
  • To: "Casey Harkins" <charkins AT upl.cs.wisc.edu>, "Seth Woolley" <seth AT tautology.org>
  • Cc: Source Mage Discuss <sm-discuss AT lists.ibiblio.org>, Eric Sandall <eric AT sandall.us>
  • Subject: Re: [SM-Discuss] SourceMage Binary Grimoire Proposal
  • Date: Sun, 3 Aug 2003 18:43:46 -0400

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.


My (ontopic) comments embeded:

--------- Original Message --------
From: Casey Harkins <charkins AT upl.cs.wisc.edu>
> On Sat, 2 Aug 2003, Seth Woolley wrote:
<snip some discussion>
> I guess my only issue with this, is trusting that things compile correctly
> if it does end up compiling. Also, I would never want the larger packages
> to get recompiled on any of the client machines.
>
> &gt; All the packages/depends, etc, should be updated on resurrect
already, and
> &gt; if not, it's a bug.
>
> I checked at one time and didn't see anything in the cache that could
> provide this information. So either it isn't being removed, or it isn't
> being restored. The required dependencies in /var/state/sorcery/depends
> could be determined automatically on resurrection (from the spell
> DEPENDS), but I don't see how sorcery could tell which option depends were
> on/off.

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


>
> &gt; Also, I like it in sorcery for reasons of orthogonality. Having a
> &gt; separate tool seems kind of like a gentoo approach, doesn't it (from
what
> &gt; I hear)?
>
> Agreed. I just didn't want to push features into sorcery that others
> wouldn't use, and didn't want to continually maintain patches to sorcery
> if they weren't accepted.
>
> &gt; Also, NFS is one way, but I thought that if PREFER_BIN was enabled
and
> &gt; there was no local cache existing, and there was a CACHE_FALLBACK_URL
> &gt; given, it could download it via http/ftp/rsync/cvs, whatever lib_url
can
> &gt; do... Failing a non-existent cache entry on the remote site, go ahead
and
> &gt; compile it locally perhaps even using distcc. But if the cache were
on
> &gt; NFS, this would be even better because caches could be saved back
upstream
> &gt; for another computer to use in the farm. We could also provide
upload
> &gt; extensions via liburl to cvs or http/dav or ftp and publish them back
up
> &gt; that way.

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.
<snip paranoia>
<snip other stuff>
> Keep the ideas coming.
>
> -casey
<snip long quote>




Archive powered by MHonArc 2.6.24.

Top of Page