Re: New LAM package
On Tue, Jul 27, 1999 at 09:37:09AM -0400, Camm Maguire wrote:
> Agreed! There's got to be an easier way...
well, you handled this one nicely.
> > (BTW, IMO, you should upload a new 6.1 to slink-proposed-updates, the
> > current ones are unusable because of that hardcoded path bug)
> Ah, sorry! I didn't notice. Does one simply put
> slink-proposed-updates in the distribution field of the control file?
Just upload it to 'stable', dinstall will take care of it. Put something on
the changelog along the lines of "the slink version is unusable" so the
archive maintainers will let the package in.
> > I guess I can go back to fighting with mosix...
> BTW, 1) How are you thinking of doing MOSIX?
"thinking" defines it rather precisely :) There's a non-trivial ammount of
stuff that's got to be solved before MOSIX can be made a .deb package. In
particular, these good fellows at the University of Jerusalem think it's a
good idea to let _all_ your processes migrate among nodes and have a list of
non-migrateable processes. I think exactly the opposite: none migrate and
you specify which ones do. There's got to be a reson why they chose this
policy, I'm still reading.
Also, their build system, is, err... at least as nightmarish as lam's. The
kernel stuff is very well put together (mind the 'version' stuff), but some
of the utilities are kinda hackish.
And of course, there's that little detail: For some reason this is kernel
version specific. I have to look at that. The module doesn't get versioned
in the normal way (i.e., obey kernel configuration at build time) but with
an extra script after it's built. And the other little detail: this is
kernel patch (good) but I've never packaged a kernel patch (bad). I'll take
a look at pcmcia stuff.
If I can sort those, I'll post an ITP.
> 2) Is anyone interested in BSPlib?
>From what I've read, it'd be good to have it. Never looked at it, tough.