From: Auke Booij <auke@tulcod.com>
To: gentoo-soc@lists.gentoo.org, gentoo-science@lists.gentoo.org
Subject: [gentoo-science] G-CRAN weekly report #6
Date: Mon, 5 Jul 2010 21:50:10 +0200 [thread overview]
Message-ID: <AANLkTimoUmFWqH7UpZM2-ojw3LfAQESYd-Vh-di04NCk@mail.gmail.com> (raw)
Last week I promised:
"Soon to come is proper parsing of the License field, proper
translation of dependencies (the current code assumes a dependency on
foo means a dependency on dev-R/foo) and installing /usr/share/doc
files correctly."
Well, I have very good news. The License field gets parsed almost
properly, documentation files get installed almost correctly, and
dependencies are almost translated properly.
No, it's not perfect yet. If the license is really a reference to a
LICENSE file (instead of just the name of the license), it does not
get installed, nor displayed correctly. If the documentation isn't
just HTML documentation, it doesn't get installed. If a dependency is
really already part of the default R install, it's not discarded and
the package will depend on a nonexistent package, and this is
something I'd like to hear your thoughts on (see below).
Unfortunately, g-common isn't really getting anywhere yet. I hope some
more emailing will get us started, but else I'll be developing my own
system. If I will, then a big advantage would be that I can simply
implement it the way I'd like to, instead of having to convince the
other two GSoC devs first ;-)
Alright, discarding dependencies. Some (a lot of) CRAN-style packages
depend on libraries which already get installed as part of the R
program. These dependencies should, for our purposes anyway, simply be
discarded, but to do this I do need to know what libraries are part of
the default R install, which means listing R's files, and I'd like you
guys to tell me how to do this. As far as I can see, the following are
the options and I'd like to hear which you would prefer:
-use "qlist" or "equery files"
-read it from the vdb
-hardcode the list of builtin R libraries
-read it from the filesystem directly (note: this would mean that some
correct dependencies are discarded as well, but it is a very
lightweight and independent solution)
Pros, cons? Opinions wanted!
Up for next week is, first of all, finishing the dependency stuff, and
if I'm lucky some initial development on g-common. The week after that
I will still be working on g-common, and perhaps do some initial
QA.
next reply other threads:[~2010-07-05 19:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-05 19:50 Auke Booij [this message]
2010-07-05 22:15 ` [gentoo-science] G-CRAN weekly report #6 Neil Shephard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimoUmFWqH7UpZM2-ojw3LfAQESYd-Vh-di04NCk@mail.gmail.com \
--to=auke@tulcod.com \
--cc=gentoo-science@lists.gentoo.org \
--cc=gentoo-soc@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox