[gentoo-science] sci team help

[gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hi all,

I would like to call for help for the sci team. Lately, we are taking
care of sometimes old packages, sometimes packages that we don't use but
are quite popular so we want to keep in the tree. Our time is limited,
bug list is barely reducing, and requests for new packages are piling
up.

There are plenty of interesting projects the sci team could start. But
we just don't do because we are understaffed. Examples of such projects
are: grid-aware tools, homepage page renewal, more docs, test-suites for
packages, more collaboration with hp-cluster. I also know some widely
used packages are not in the tree because they need a lot of time to
package/maintain. In my field such examples are: iraf and midas in
sci-astronomy, geant-4 in hep, R-packages, many numerical libraries,
etc...

So what could we do to get more help: call for new recruits, convince
more devs to join the sci herd, get proxied packages, more overlay
maintainers? (in the past, there was a similar thread [1]). I could
train a new dev in anyone interested, I would have more time in 2 weeks.

Regards,

--
Sébastien

[1] http://thread.gmane.org/gmane.linux.gentoo.science/272


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[C Y]

--- Sébastien Fabbro <bicatali@gentoo.org> wrote:

> So what could we do to get more help: call for new recruits, convince
> more devs to join the sci herd, get proxied packages, more overlay
> maintainers? (in the past, there was a similar thread [1]). I could
> train a new dev in anyone interested, I would have more time in 2
> weeks.

I might be interested in training as a dev - I have some experience
with ebuilds.

Cliff


      ____________________________________________________________________________________
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more!
http://tv.yahoo.com/collections/3658 
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Yuriy Rusinov]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Hello, Sebastien !


 In my field such examples are: iraf and midas in
> sci-astronomy, geant-4 in hep, R-packages, many numerical libraries,
> etc...


My name is Yuriy Rusinov. I have a Ph.D. degree in astrometry, obtained in
the Institute of Applied Astronomy.  Now I am working in the Scientific
Technical Center "Radar" geoinformational system development.

I could
> train a new dev in anyone interested, I would have more time in 2 weeks.


I work using Gentoo Linux since 2003. Which way I can help for
gentoo-science ?



-- 
Best regards,
Sincerely yours,
Yuriy Rusinov

[-- Attachment #2: Type: text/html, Size: 996 bytes --]

Re: [gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

For those who would like to join: as I said, I won't be much available
until early November, but some other devs might.

You also might want to see if you would like simply commit access to the
science overlay, to maintain a few packages.

Meanwhile here are some pointers and tips to get you started:
- get full knowledge of gentoo docs, handbooks [1] and projects
- try to help bugs and problems [2]
- lurk in gentoo-science, gentoo-dev lists archives [3]
- learn the developer handbook [4] and manual [5] developers
- lurk or participate in irc channels #gentoo-science, #gentoo-dev,
#gentoo-dev-help

As far as scientific packages are concerned, we putting more and more
emphasis on tests. Providing ways to test packages, by a src_test
function or some kind of test recipe is important. Scientists like to
get right results (well as much as the software can give)!

--
Sébastien 

[1] http://www.gentoo.org/doc/en/list.xml
[2] http://bugs.gentoo.org
[3] http://www.gentoo.org/main/en/lists.xml
[4] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
[5] http://devmanual.gentoo.org
[6] http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Redouane Boumghar]

Hello everyone,

I'm a young physicist and digital image analyst and never used
anything else than Linux (Debian) or Free BSD.
It's been 5 years I am using Gentoo and I would gladly help the
scientific community.

I'll have more time in early November as well so I'll check
the tips and pointers that Sebastien pointed. 
I don't know yet on which side I could help the most but
I could help the devs with bugs and algorithms for sure.

I'll go to have some beers at #gentoo-science, #gentoo-dev,
and #gentoo-dev-help if I have some time in the next days(nights) :-)


See you soon,


-- 
Redouane BOUMGHAR, alias "rodie"  Getting involved !
Physics, Remote Sensing and Digital Imagery

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Donnie Berkholz]

On 19:39 Mon 15 Oct     , Sébastien Fabbro wrote:
> I would like to call for help for the sci team. Lately, we are taking
> care of sometimes old packages, sometimes packages that we don't use but
> are quite popular so we want to keep in the tree. Our time is limited,
> bug list is barely reducing, and requests for new packages are piling
> up.
> 
> There are plenty of interesting projects the sci team could start. But
> we just don't do because we are understaffed. Examples of such projects
> are: grid-aware tools, homepage page renewal, more docs, test-suites for
> packages, more collaboration with hp-cluster. I also know some widely
> used packages are not in the tree because they need a lot of time to
> package/maintain. In my field such examples are: iraf and midas in
> sci-astronomy, geant-4 in hep, R-packages, many numerical libraries,
> etc...
> 
> So what could we do to get more help: call for new recruits, convince
> more devs to join the sci herd, get proxied packages, more overlay
> maintainers? (in the past, there was a similar thread [1]). I could
> train a new dev in anyone interested, I would have more time in 2 weeks.

Just a cautionary note:

However much we might be able to use the extra help, we need to make 
sure to keep our developer standards high.

I think a good way to start is to make the overlay an "accepted" 
solution for where to keep packages. Get more people participating in 
the overlay, and even be willing to move packages from the main tree to 
the overlay if there's non-devs willing to help with things that are 
poorly maintained.

The overlay worked great to get you to join. =)

Thanks,
Donnie
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Jukka Ruohonen]

While I too might have some interest in developing particularly the scientific 
packages, Donnie's comment made me to wonder whether the idea of "support teams" 
(cf. arch testers) was buried? 

I think this idea that was mentioned in the previous thread would be especially 
suitable for the sci-team and its packages that often require, besides the normal 
ebuild practices, some special expertise to carry out full runtime testing. Or would 
these teams just mean extra work for the actual developers? Will a presumably small 
community using the scientific packages need this kind of an extra layer? 

Perhaps these "support teams" would also narrow the (assumed) threshold of 
participating in the overlay. (I see that "herd testers" are mentioned in the 
overlay, but as a long-time Gentoo user I have no knowledge what these testers are; 
this also demonstrates the little obscurity that surrounds all overlays from an 
end-user perspective.)

Regards,

Jukka Ruohonen.


> > So what could we do to get more help: call for new recruits, convince
> > more devs to join the sci herd, get proxied packages, more overlay
> > maintainers? (in the past, there was a similar thread [1]). I could
> > train a new dev in anyone interested, I would have more time in 2 weeks.
> 
> Just a cautionary note:
> 
> However much we might be able to use the extra help, we need to make 
> sure to keep our developer standards high.
> 
> I think a good way to start is to make the overlay an "accepted" 
> solution for where to keep packages. Get more people participating in 
> the overlay, and even be willing to move packages from the main tree to 
> the overlay if there's non-devs willing to help with things that are 
> poorly maintained.
> 
> The overlay worked great to get you to join. =)
> 
> Thanks,
> Donnie
> -- 
> gentoo-science@gentoo.org mailing list
> 

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Markus Luisser]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]


I could also sacrify some time to help - I'm not much of a programmer I fear, 
but testing or writing a small script every know and then is certainly not 
beyond me.

On Tuesday 16 October 2007, Jukka Ruohonen wrote:
> Perhaps these "support teams" would also narrow the (assumed) threshold of
> participating in the overlay. (I see that "herd testers" are mentioned in
> the overlay, but as a long-time Gentoo user I have no knowledge what these
> testers are; this also demonstrates the little obscurity that surrounds all
> overlays from an end-user perspective.)

Full ack to that, that's what things look like for me. I admit that I'm not 
following developments on gentoo so closely anymore, since I simply do not 
have the time, but even so, it can be a bit confusing to find one's way 
around the numerous overlays, official and not-so-official homepages and 
whatnot.

As Jukka expresses it, maybe that is just perceived but that doesn't make it 
less real.

On Tuesday 16 October 2007, Sébastien Fabbro wrote:
> So what could we do to get more help: call for new recruits, convince
> more devs to join the sci herd, get proxied packages, more overlay
> maintainers?

For me personally, I'd like to see something like a ToDo or AdoptAnEbuild list 
somewhere, perhaps sorted by complexity, so that people that are interested 
can more easily try their hands on it. Just pointing people to bugs.g.o feels 
a little bit like Augeias' stable cleaning with no idea where to begin.

Moreover I guess there are plenty of things that do not have a bug report 
attached to them - stuff like hunting down the changed dependencies of a new 
software release or testing the stability of a simple version bump and things 
the like.

That might create a bit more overhead for 'real' developers but it might also 
lower the treshhold for new people.

Just my two cents.

Cheers

Markus

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 1451 bytes --]

On Tue, 2007-10-16 at 00:02 +0300, Jukka Ruohonen wrote:
> While I too might have some interest in developing particularly the scientific 
> packages, Donnie's comment made me to wonder whether the idea of "support teams" 
> (cf. arch testers) was buried? 

Becoming an arch tester is (I think) still possible, and a sci tester is
definitely possible. You need to answer the ebuild development quiz.
People interested should read the pointers mentioned in a previous email
of this thread, and mail me or sci@g.o. so we can gather all requests.

> I think this idea that was mentioned in the previous thread would be especially 
> suitable for the sci-team and its packages that often require, besides the normal 
> ebuild practices, some special expertise to carry out full runtime testing. Or would 
> these teams just mean extra work for the actual developers? Will a presumably small 
> community using the scientific packages need this kind of an extra layer? 

Possible ways to have some tests procedures:
- bugzilla: add the test procedure to an existing new package bug, or
file a new bug properly assigned to the herd mentioned in the ebuild
metadata.xml.
- overlay: write test procedures, just as the emacs project did [1]

I will see with overlay.g.o staff if we can open our overlay wiki to the
gentoo science community and make it a more general wiki.

--
Sébastien

[1] http://overlays.gentoo.org/proj/emacs

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]


> I will see with overlay.g.o staff if we can open our overlay wiki to the
> gentoo science community and make it a more general wiki.

Answer: can be done. People without overlay access and interested in
making our wiki a nice one, mail sci@g.o with your ideas, or pop up in
#gentoo-science.

-- 
Sébastien

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Andrey G. Grozin]

On Mon, 15 Oct 2007, Donnie Berkholz wrote:
> I think a good way to start is to make the overlay an "accepted"
> solution for where to keep packages. Get more people participating in
> the overlay, and even be willing to move packages from the main tree to
> the overlay if there's non-devs willing to help with things that are
> poorly maintained.
The original cryos' idea when he created the science overlay was a place 
to develop ebuilds until they become mature enough to be moved to the main 
tree (I can dig his original post about this subject). He suggested that 
ebuilds whould, in most cases, be moved to the main tree quickly enough.

Gentoo users are not instructed to use overlays. Most of them just don't 
know about them. Hunting for an interesting package in many tens of 
overlays present at overlays.gentoo.org is not easy. A package in an 
overlay can depend on some other packages in the same overlay, etc. So, 
from the user's perspective, overlays are obscure (which ones should I add 
to my tree? Where are packages that are of interest for me? Should I 
browse all this stuff at overlays.gentoo.org? Oh my...) They also add an 
extra layer of complexity (should I install layman? How to use it? Are the 
overlays updated when I do emerge --sync? What, I should do this by hand? 
Oh my...) And Gentoo is complex enough for users even without this extra 
layer of new and unknown concepts.

If we *really* want to divide packages into first-class citizens and 
second-class ones (residing in overlays), we should do several things.

1. Inform users *prominently* that some interesting packages don't live in 
the main portage tree (currently, not many users know this).

2. Write a chapter about overlays and layman for the Gentoo user guide.

Who will decide which packages are first-class citizens and which are not? 
What are the criteria?

Andrey
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Donnie Berkholz]

On 12:01 Tue 16 Oct     , Andrey G. Grozin wrote:
> The original cryos' idea when he created the science overlay was a place to 
> develop ebuilds until they become mature enough to be moved to the main 
> tree (I can dig his original post about this subject). He suggested that 
> ebuilds whould, in most cases, be moved to the main tree quickly enough.

OK, sure, but historic reasons are not future reasons. If things should 
change, this is not a reason to hold it back.

> Gentoo users are not instructed to use overlays. Most of them just don't 
> know about them. Hunting for an interesting package in many tens of 
> overlays present at overlays.gentoo.org is not easy.

There is http://www.gentoo.org/proj/en/overlays/userguide.xml -- for 
some reason, it doesn't appear to be linked from the main docs section. 
I just asked in #gentoo-doc about this.

I agree that hunting could be difficult, but most of the project (rather 
than developer-owned) overlays are topical by definition. If I'm looking 
for a scientific application, it shouldn't take a leap of logic to try 
the science overlay. Also, eix (a searching tool) includes a searchable 
package cache of every overlay, generated daily.

> 1. Inform users *prominently* that some interesting packages don't live in 
> the main portage tree (currently, not many users know this).

Yep.

> Who will decide which packages are first-class citizens and which are not? 
> What are the criteria?

I suggested a few.
	- Is a developer willing to commit to maintaining it?
	- Is it expected to be fairly popular, or is it extremely specific?
	- (for apps already in the tree) Is it unmaintained? Should it be 
		moved to an overlay?

Thanks,
Donnie
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Tue, 2007-10-16 at 00:20 -0700, Donnie Berkholz wrote:
> On 12:01 Tue 16 Oct     , Andrey G. Grozin wrote:
> > The original cryos' idea when he created the science overlay was a place to 
> > develop ebuilds until they become mature enough to be moved to the main 
> > tree (I can dig his original post about this subject). He suggested that 
> > ebuilds whould, in most cases, be moved to the main tree quickly enough.
> 
> OK, sure, but historic reasons are not future reasons. If things should 
> change, this is not a reason to hold it back.
> 

These days, the overlay is more of a sandbox for devs and a place to
ease package transition from bugzilla to the tree. Why some packages are
still in the overlay rather than in the main tree to me is only a matter
of manpower. Hopefully some day Gentoo will get more modular- right now
our cvs repository is gigantic and as you all know this means more
inertia. 

> > 1. Inform users *prominently* that some interesting packages don't live in 
> > the main portage tree (currently, not many users know this).
> 
> Yep.
> 

Well anyone who has commit access to the overlay is welcome to add
anything relevant to the wiki trac page.

> 	- Is it expected to be fairly popular, or is it extremely specific?

It's hard to judge this. We have the CC and votes at bugs.gentoo.org,
but as useful as bugzilla could be, it is not the zen-est interface.
Many times I feel that our tendency to resolve all issues with bugzilla
reduces productivity both for bugs reporters and bugs resolvers.

Anyway it is nice to see the science project is generating interest.

--
Sébastien

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Jukka Ruohonen]

> > Who will decide which packages are first-class citizens and which are not? 
> > What are the criteria?
> 
> I suggested a few.
> 	- Is a developer willing to commit to maintaining it?
> 	- Is it expected to be fairly popular, or is it extremely specific?
> 	- (for apps already in the tree) Is it unmaintained? Should it be 
> 		moved to an overlay?

The first criteria is naturally a prerequisite for any package. But I also share the 
concerns raised by Andrey.

Somehow, I feel, personally, that the sci-packages should constitute an exception 
from the general rules regarding overlays. I mean that when a person chooses to use 
something from, say, Xfce overlay, the use of an overlay is rather natural and 
pleasant, but when a person is "forced" to use an overlay in order to write a Ph.D 
thesis, the use of an overlay can be far from pleasant. In my opinion overlays can 
not escape additional concerns regarding quality and trust, and these concerns are 
much more strongly felt when we are dealing with scientific packages. Again the 
keyword may just be the perception.

And as Sébastien mentioned, this is an area in which the build process and runtime 
behavior should be rock solid, the former preferably being accompanied by as many 
tests as is possible. Do not get me wrong: all packages that I have used from the 
sci-overlay have been high-quality ones, but for the mentioned reasons I see no 
point in having an overlay that possibly (would? will?) contain unmaintained ebuilds 
with little or no testing. Again I see this as an issue specifically related to the 
scientific packages.

Also, given that we are dealing with scientific software, the minority of the 
packages will fall under the "generic and popular" category, while the rest will 
surely be more or less specific. I see that we have eleven sci-categories in the 
main tree. Most likely packages in sci-electronics will be extremely specific for 
people doing work with packages in the sci-geosciences category. I doubt that 
popularity is such a good criteria in choosing which scientific packages deserve to 
be in the main tree. I would rather like to ask what kind of internal representation 
the sci team has? Are the staffing needs especially bad in some areas?

Again these were just small and perhaps irrelevant opinions from an user of the 
scientific packages.

Thanks,

Jukka Ruohonen.

-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Donnie Berkholz]

On 13:04 Tue 16 Oct     , Jukka Ruohonen wrote:
> Somehow, I feel, personally, that the sci-packages should constitute 
> an exception from the general rules regarding overlays. I mean that 
> when a person chooses to use something from, say, Xfce overlay, the 
> use of an overlay is rather natural and pleasant, but when a person is 
> "forced" to use an overlay in order to write a Ph.D thesis, the use of 
> an overlay can be far from pleasant. In my opinion overlays can not 
> escape additional concerns regarding quality and trust, and these 
> concerns are much more strongly felt when we are dealing with 
> scientific packages. Again the keyword may just be the perception.

"keyword" is the key word. If we were to do this, we'd have to manage 
the keywords and masking more carefully (or at all!) in the overlays. 
That gives a better indication of quality than the arbitrary assumption 
of "portage tree good, overlay bad" that we have now.

Thanks,
Donnie
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Nuno Sucena Almeida]

Hi,
	I can help the team out, I've done or improved a few ebuilds for packages 
that I regularly use and have gentoo installed on many high-end 64bit (and 
some 32bit) machines, which I or other use for computational physics. Besides 
that, I've been using linux for the past 12 years...

							Nuno

On Monday 15 October 2007 02:39:02 pm Sébastien Fabbro wrote:
> I would like to call for help for the sci team. Lately, we are taking

-- 
http://aeminium.org/slug/
--
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[M. Edward (Ed) Borasky]

Sébastien Fabbro wrote:
> Hi all,
> 
> I would like to call for help for the sci team. Lately, we are taking
> care of sometimes old packages, sometimes packages that we don't use but
> are quite popular so we want to keep in the tree. Our time is limited,
> bug list is barely reducing, and requests for new packages are piling
> up.
> 
> There are plenty of interesting projects the sci team could start. But
> we just don't do because we are understaffed. Examples of such projects
> are: grid-aware tools, homepage page renewal, more docs, test-suites for
> packages, more collaboration with hp-cluster. I also know some widely
> used packages are not in the tree because they need a lot of time to
> package/maintain. In my field such examples are: iraf and midas in
> sci-astronomy, geant-4 in hep, R-packages, many numerical libraries,
> etc...
> 
> So what could we do to get more help: call for new recruits, convince
> more devs to join the sci herd, get proxied packages, more overlay
> maintainers? (in the past, there was a similar thread [1]). I could
> train a new dev in anyone interested, I would have more time in 2 weeks.
> 
> Regards,
> 
> --
> Sébastien
> 
> [1] http://thread.gmane.org/gmane.linux.gentoo.science/272
> 
I've been following this thread, and I'll have to admit I'm often 
tempted to volunteer as a dev in the sci herd. But I just never seem to 
take the step from hard-core volunteer tester. I'm not sure why, but I 
think for now it's still about all I have time to do -- test stuff, file 
bugs, encourage the existing devs, etc. A few more specific comments:

1. I'm not sure the idea of integrating, say, R packages, into Portage 
is a good one. Debian has a lot of R packages in their repository, but 
that's mainly because one developer, Dirk Eddelbuettel, took that on as 
a personal mission. For that matter, I don't know that Portage really 
*needs* to have "tight" integration with any other package management 
systems. In other words, does a CPAN Perl package really need to be 
wrapped in an ebuild, or could a Gentoo user just as easily install CPAN 
packages directly? The same goes for Ruby gems -- it's only marginally 
more convenient for a Rubyist to have gems in Portage, and you'll never 
have them *all. If you have the developer resources, sure, why not, but 
aren't there better things the developers could be doing? In any event, 
I use R and its packages heavily and don't see the need to "emerge 
Rcmdr" -- R's native package management system is fine. So is Ruby's 
"rubygems" package management system.

2. Don't be afraid to kick something out of the distro if nobody wants 
to maintain it. It's no big deal to install a package from upstream 
source. As far as I'm concerned, in most cases the only difference is 
that it ends up in /usr/local instead of in /usr and I have to manually 
load the dependencies.

3. I think the distinction between testing/unstable but in the tree and 
testing/unstable but in an overlay is a good one. As one of the 
documents says, things in the overlay *will* break your system. I 
haven't had one break to the point of needing a rebuild in a couple of 
years, but I've come close. You have to back stuff up and be careful 
anyhow, so why not have the software available? :)
-- 
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Sébastien Fabbro]

[-- Attachment #1: Type: text/plain, Size: 1870 bytes --]

On Tue, 2007-10-16 at 06:57 -0700, M. Edward (Ed) Borasky wrote:

> 1. I'm not sure the idea of integrating, say, R packages, into Portage 
> is a good one. Debian has a lot of R packages in their repository, but 
> that's mainly because one developer, Dirk Eddelbuettel, took that on as 
> a personal mission. For that matter, I don't know that Portage really 
> *needs* to have "tight" integration with any other package management 
> systems. In other words, does a CPAN Perl package really need to be 
> wrapped in an ebuild, or could a Gentoo user just as easily install CPAN 
> packages directly? The same goes for Ruby gems -- it's only marginally 
> more convenient for a Rubyist to have gems in Portage, and you'll never 
> have them *all. If you have the developer resources, sure, why not, but 
> aren't there better things the developers could be doing? In any event, 
> I use R and its packages heavily and don't see the need to "emerge 
> Rcmdr" -- R's native package management system is fine. So is Ruby's 
> "rubygems" package management system.

Not saying 100 R packages  => 100 ebuilds, but passing proper flags,
building deps and all could be wrapped in a nice gentoo way (btw, is
paludis doing this?). Anyway this was just a project idea in a todo list
and should go to another thread, or the corresponding bug. 

> 2. Don't be afraid to kick something out of the distro if nobody wants 
> to maintain it. It's no big deal to install a package from upstream 
> source. As far as I'm concerned, in most cases the only difference is 
> that it ends up in /usr/local instead of in /usr and I have to manually 
> load the dependencies.

This is also an area where we could use some help. Do you feel any
packages are unmaintained or could be removed? If yes, file a bug, say
your word on the wiki, ...

-- 
Sébastien

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-science] sci team help

[Nuno Sucena Almeida]

On Tuesday 16 October 2007, Sébastien Fabbro wrote:
> > systems. In other words, does a CPAN Perl package really need to be
> > wrapped in an ebuild, or could a Gentoo user just as easily install CPAN
> > packages directly? The same goes for Ruby gems -- it's only marginally

In the case of perl, g-cpan seems to take that role:

	http://www.gentoo.org/proj/en/perl/g-cpan.xml

maybe something similar for R would work too.

								Nuno
-- 
http://aeminium.org/slug/
--
gentoo-science@gentoo.org mailing list

Re: [gentoo-science] sci team help

[Donnie Berkholz]

On 16:03 Tue 16 Oct     , Sébastien Fabbro wrote:
> On Tue, 2007-10-16 at 06:57 -0700, M. Edward (Ed) Borasky wrote:
> 
> > 1. I'm not sure the idea of integrating, say, R packages, into Portage 
> > is a good one. Debian has a lot of R packages in their repository, but 
> > that's mainly because one developer, Dirk Eddelbuettel, took that on as 
> > a personal mission. For that matter, I don't know that Portage really 
> > *needs* to have "tight" integration with any other package management 
> > systems. In other words, does a CPAN Perl package really need to be 
> > wrapped in an ebuild, or could a Gentoo user just as easily install CPAN 
> > packages directly? The same goes for Ruby gems -- it's only marginally 
> > more convenient for a Rubyist to have gems in Portage, and you'll never 
> > have them *all. If you have the developer resources, sure, why not, but 
> > aren't there better things the developers could be doing? In any event, 
> > I use R and its packages heavily and don't see the need to "emerge 
> > Rcmdr" -- R's native package management system is fine. So is Ruby's 
> > "rubygems" package management system.
> 
> Not saying 100 R packages  => 100 ebuilds, but passing proper flags,
> building deps and all could be wrapped in a nice gentoo way (btw, is
> paludis doing this?). Anyway this was just a project idea in a todo list
> and should go to another thread, or the corresponding bug. 

Paludis does support CRAN, according to its docs. I don't use it so I 
can't comment on the details.

Portage already has g-cpan.pl to automatically integrate Perl; there's 
projects to do the same thing with the Python Cheese Shop and Ruby gems 
as well.

Thanks,
Donnie
-- 
gentoo-science@gentoo.org mailing list