Public SourceMage Discussion List

[Lubomir Blaha <tritol AT trilogic.cz>]

On Mon, Jun 27, 2005 at 05:57:57PM -0700, Eric Sandall wrote:
>  What you might want to do is just use distcc on the laptop and
> desktop. Have the laptop send all of it's compilation to the desktop
> and do none of it's own, then Sorcer will use your desktop to compile
> the packages and then install on the laptop. Alternatively you could
> have both your machines use the same cache files from installed spells,
> but then you'll have to compile for the lowest machine (your 486 laptop)
> and then have /var/cache/sorcery NFS (or any other networked filesystem)
> mounted on the laptop from the desktop. Once you compile a package on
> the desktop it'll also be available for resurrection on the laptop.
>  Personally I'd go with the distcc route so that your desktop and
> laptop can have different options for the packages (since you may not
> want all the options on your laptop (e.g. KDE) that you do on the
> desktop).

Distcc is interesting idea. I already know it exist but didn't know how
it works. Now I'm little smarter than yesterday, thanks :).

But distcc brings some other problems. The laptop have no network device
so I should "emulate" net via paralel or serial port (is it possible?).
There is no cdrom too, so another thing to solve (to install basic set
of spells).

Sync via /var/cache/sorcery is possible (I already done it with another
installation) but I don't want this. The diferencies between both systems
are too big.

I don't need "full featured" SM system on laptop. My idea is install
only few spells to bring the hw up (kernel, init, shell, vim, directfb
etc) and still have way to upgrade this spells when new versions will
be avaiable. Seems this requires some kind of chrooted enviroment on
desktop. Or am I wrong?

        Lubomir


-- 
If you ever want to have a lot of fun, I recommend that you go off and program
an imbedded system.  The salient characteristic of an imbedded system is that
it cannot be allowed to get into a state from which only direct intervention
will suffice to remove it.  An imbedded system can't permanently trust 
anything
it hears from the outside world.  It must sniff around, adapt, consider, sniff
around, and adapt again.  I'm not talking about ordinary modular programming
carefulness here.  No.  Programming an imbedded system calls for undiluted
raging maniacal paranoia.  For example, our ethernet front ends need to know
what network number they are on so that they can address and route PUPs
properly.  How do you find out what your network number is?  Easy, you ask a
gateway.  Gateways are required by definition to know their correct network
numbers.  Once you've got your network number, you start using it and before
you can blink you've got it wired into fifteen different sockets spread all
over creation.  Now what happens when the panic-stricken operator realizes he
was running the wrong version of the gateway which was giving out the wrong
network number?  Never supposed to happen.  Tough.  Supposing that your
software discovers that the gateway is now giving out a different network
number than before, what's it supposed to do about it?  This is not discussed
in the protocol document.  Never supposed to happen.  Tough.  I think you 
get my drift.