Gentoo Archives: gentoo-soc

From: Auke Booij <auke@××××××.com>
To: gentoo-soc@l.g.o
Cc: bicatali@g.o
Subject: [gentoo-soc] Two ideas: R package installer (CRAN) and per-user daemons
Date: Thu, 18 Mar 2010 14:59:05
Message-Id: 8f234f341003180758i4f095a0atf1dccaebf7ac66e0@mail.gmail.com
1 Hey there,
2
3 Google Summer of Code is slowly taking off, I'd like to claim a spot.
4
5 Two ideas I'd like to expand on behalf of Gentoo are:
6 1. R package installer (also see gentoo-wiki.com). R has a lot of
7 additional packages, so it is not feasible to manually create and
8 maintain ebuilds for all of them. There are a number of databases
9 containing these additional packages, including CRAN and Bioconductor.
10 Three reasonable solutions are: 1. create a big ebuild with loads and
11 loads of USE flags which compiles and installs the wanted R packages
12 as one big package (not the best, since this is exactly what we want
13 to avoid with Gentoo, and we would indeed need loads of use flags), 2.
14 generate ebuilds for all packages (this would need regular running of
15 scripts, and would probably need for its own overlay), 3. install to
16 the filesystem without letting the package manager know about anything
17 (ehm... I guess this is not a reasonable solution, after all). Are
18 there any ideas about how to solve this, and how R usually installs
19 them? Sebastien fabbro, I cc'd you, are you still interested in
20 mentoring this?
21
22 2. Per-user daemons. Currently, there are some daemons, like
23 PulseAudio, jackd, several download daemons, and soon possibly X.org
24 (which will no longer need to run as root, and really should run as a
25 normal user), which run as specific users, instead of root or a
26 systemwide daemon-specific user. There is currently no framework for
27 launching these daemons at all, and the current solution is to either
28 make users figure out their own solution (a popular one is an extra
29 line in .xinitrc), or to set the username in some conf.d file, thus
30 disabling the possibility to run several of them for different users.
31 I would like to develop an extension to our current init.d system
32 which will enable users to write and start their own init scripts,
33 which at first only run as themselves, not as another user. This would
34 make it possible to cleanly launch several identical daemons for
35 several users. This project would involve either writing a new
36 additional init.d system, or extend our current system. I would like
37 to know 1. if you guys are understanding a word of what I'm saying at
38 all 2. if this would be an interesting idea (I think it is, of course)
39 3. anyone has any ideas or would like to mentor me.
40
41 Thanks for your ideas.
42 Auke Booij "tulcod".

Replies