[rkward-devel] rkward on mac

[meik michalke]

hi,

Am Mittwoch 30 November 2011, 14:13:44 schrieb Thomas Friedrichsmeier:
> On Tuesday 29 November 2011, meik michalke wrote:
> > erm, there is one now: 800MB. to say it with famous words of john
> > crichton: "that's big. that's really big."
> 
> well, yes that *is* big. I suppose, feeding this through a good compressor
> does not help much?

before: 804, after: 801. i'd say it's a "no".

i mounted the .dmg image and examined its contents. 100MB are occupied by 
virtuoso, a part of the semantic desktop features that ruined kmail2 big time. 
ffmpeg and mysql are further candidates RKWard might not need so bad. if they 
were removed, the image would still have 650MB. the image also uses 90MB for 
gcc, which i think is probably not so bad if it enables R to build source 
packages.

a colleague of mine tried to install the image, but we didn't yet fully figure 
out what has to be done in addition to make it really work...

> Can macports also build a source meta package? Once we start looking into
> distributing a binary package, we need to provide (or at least offer) that,
> too, for GPL-compliance.

well, i didn't find a dedicated feature for this, but we could zip up 
$install_prefix/var/macports/software, which holds .tbz2 archives of the 
downloaded sources (even if they were fetched via svn).

> BTW, one question just occurred to me: In the rkward wrapper script, the
> location of the R binary is hard-coded (at build time). Does this have to be
> adjusted (and is there a way to adjust it), when users install the package?
> Or are they forced to install to a fixed location, anyway?

"installation" here means drag&dropping the app in the image to your 
applications folder. this will copy everything to /opt/rkward, so the path is 
still ok. i don't know yet if you can set environment varaibles and the like.

> In my experience with the window binaries, the "leaves" of the
> dependency-tree are not all that large in comparison. But the further you
> move down in the depends, the more difficult it is probably to get things
> right.

a MacPorts build is not as painful as i had imagined before. if bundling the 
beast turns out to be too tiresome to get working, that's perhaps a good 
fallback solution. it is certainly preferable for updates!


viele grüße :: m.eik

-- 
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20111201/0e27e84e/attachment.sig>