FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-23-2008, 07:28 PM
Matthew Miller
 
Default R-devel going away

On Thu, Oct 23, 2008 at 09:34:56AM -0500, Jason L Tibbitts III wrote:
> MM> Where do R packages installed this way go?
> Into the installing user's home directory.

In that case, sounds fine to me.

--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-23-2008, 08:31 PM
Toshio Kuratomi
 
Default R-devel going away

Tom "spot" Callaway wrote:
> On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:
>> Better solutions:
>>
>> * add it to comps.xml
>> * move 'R' to R-core, and add 'R' which depends on 'R-core' +
>> 'R-devel'
>>
>>
>>> * The size of the R-devel is tiny, about 440K installed.
>> You miss its dependencies:
>>
[long list of dependencies]

>
> These are very good points, thanks Enrico. What would people think about
> doing the suggested R/R-core/R-devel split instead? Users would still be
> able to get everything with yum install R, it would meet the guidelines,
> and minimal installs with R can simply have R-core.
>
Not an R user but I like this plan.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-23-2008, 09:10 PM
James Antill
 
Default R-devel going away

On Thu, 2008-10-23 at 19:41 +0100, José Matos wrote:
> On Thursday 23 October 2008 19:22:07 James Antill wrote:
> > Well it kinda fits the "people expect foo-core + additions" _assuming_
> > CRAN is a requirement, but really why don't we just package more of the
> > R modules so CRAN usage isn't a requirement?
>
> There are more than 1500 modules (the have been growing at an exponential rate
> in the last years). So while we would like to see more R packages in Fedora in
> are not even near to have a reasonable subset of R packaged.

My main concern was that you could use that argument a lot (there are
probably still more unpackaged libc using things than packaged).
But I ran:

repoquery --whatrequires '*-devel' |
fgrep -v -- '-devel-' |
fgrep -v -- '-static-'

...and there's a lot of stuff there, including a lot of the "small"
languages (and perl-core, although that's not actually required by perl
which seems like a bug). So this isn't unusual (bad spot for asking,
instead of just doing it like everyone else .

--
James Antill <james@fedoraproject.org>
Fedora

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-24-2008, 01:37 AM
Matthew Saltzman
 
Default R-devel going away

On Thu, 2008-10-23 at 19:41 +0100, José Matos wrote:
> On Thursday 23 October 2008 19:22:07 James Antill wrote:
> > Well it kinda fits the "people expect foo-core + additions" _assuming_
> > CRAN is a requirement, but really why don't we just package more of the
> > R modules so CRAN usage isn't a requirement?
>
> There are more than 1500 modules (the have been growing at an exponential rate
> in the last years). So while we would like to see more R packages in Fedora in
> are not even near to have a reasonable subset of R packaged.
>
> So for the moment CRAN is really a requirement to use R in Fedora.

This situation seems to cry out for a solution like cpan2rpm for the
Perl Archive.
--
Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-24-2008, 01:39 AM
Jason L Tibbitts III
 
Default R-devel going away

>>>>> "MS" == Matthew Saltzman <mjs@clemson.edu> writes:

MS> This situation seems to cry out for a solution like cpan2rpm for
MS> the Perl Archive.

I believe the existing R2spec handles this nicely.

- J<

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-24-2008, 06:52 AM
José Matos
 
Default R-devel going away

On Thursday 23 October 2008 23:08:53 George N. White III wrote:
>
> There have always been conflicts between the CRAN package system and
> Fedora or other linux packaging Guidelines. Users can install CRAN
> packages without root privileges, but then the search function won't know
> about the user's packages, and packages that rely on other library (gsl,
> hdf5, etc) still need -dev RPM's. Linux distros should not be trying to
> enforce guidelines
> for mainstream packages with their own robust package management and
> archive networks.

Playing devil's advocate I should remark that first each language is building
its own repository and packaging system in a sense we have lots of equivalents
of (yum+rpm) for each language (perl, php, python, R, tex, ...).

On the other hand for the system to be really useful it must use the least
possible denominator (read the dumbest wins- pun intended ;-) ).

> Instead, they should look for ways to improve support
> for users who rely on those 3rd party systems. For example:
>
> R-base: basic runtime without dev dependencies, for sites that provide
> binary CRAN packages (e.g., on a shared directory) so users don't need to
> do compiles.
>
> R-core: R-base + -dev dependencies for those who want to install source
> packages from CRAN (e.g., most individual R users)
>
> R-X-sup(plement): -dev dependencies needed to build package X (e.g.,
> R-hdf5-sup requires hdf5-dev for the hdf5 package from CRAN, gsl-dev
> for gsl, etc.). These aren't strictly necessary, but would serve to
> link package versions on CRAN with the versions of the support libs in
> Fed,
> something that can take some effort (e.g., peeking in the sources) to
> determine. For sites
> where users need to ask admins to install libraries, this simplifies
> the problem of telling the admin which libs to install.

I am not sure if this is right path or the right balance.

Another possible choice is to expand R2spec in scope and not only create rpm
spec files but to discover the different dependencies and how they are solved
inside.

There is no reason that we can not rebuild the whole CRAN (or almost all of
it) automatically.

> In the long run, linux distros should look at devising ways to capture
> information from these
> 3rd party package managers to help resolve dependencies automatically.

As everything with free software the survival of the fittest means that this
will only happen if there are people interested in spending resources to make
this possible.
--
José Abílio



--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-24-2008, 07:18 AM
José Matos
 
Default R-devel going away

On Thursday 23 October 2008 15:30:48 Pierre-Yves wrote:
> Would the lake of packager be a suffisant answer ?
>
> FYI:
> http://rpms.famillecollet.com/rpmphp/rpm.php?type=R

It would be interesting to get a monthly report like this in fedora-r-devel
periodically (monthly).

I am aware that I have packages to update and I was expecting for R-2.8.0 to
be released to update them. In any case a table like that always helps in
those cases where the update slipped under the radar. :-)

> Regards,
>
> Pierre

--
José Abílio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-24-2008, 07:43 AM
Pierre-Yves
 
Default R-devel going away

José Matos wrote:

On Thursday 23 October 2008 23:08:53 George N. White III wrote:

There have always been conflicts between the CRAN package system and
Fedora or other linux packaging Guidelines. Users can install CRAN
packages without root privileges, but then the search function won't know
about the user's packages, and packages that rely on other library (gsl,
hdf5, etc) still need -dev RPM's. Linux distros should not be trying to
enforce guidelines
for mainstream packages with their own robust package management and
archive networks.


Playing devil's advocate I should remark that first each language is building
its own repository and packaging system in a sense we have lots of equivalents
of (yum+rpm) for each language (perl, php, python, R, tex, ...).


On the other hand for the system to be really useful it must use the least
possible denominator (read the dumbest wins- pun intended ;-) ).



Instead, they should look for ways to improve support
for users who rely on those 3rd party systems. For example:

R-base: basic runtime without dev dependencies, for sites that provide
binary CRAN packages (e.g., on a shared directory) so users don't need to
do compiles.

R-core: R-base + -dev dependencies for those who want to install source
packages from CRAN (e.g., most individual R users)

R-X-sup(plement): -dev dependencies needed to build package X (e.g.,
R-hdf5-sup requires hdf5-dev for the hdf5 package from CRAN, gsl-dev
for gsl, etc.). These aren't strictly necessary, but would serve to
link package versions on CRAN with the versions of the support libs in
Fed,
something that can take some effort (e.g., peeking in the sources) to
determine. For sites
where users need to ask admins to install libraries, this simplifies
the problem of telling the admin which libs to install.


I am not sure if this is right path or the right balance.

Another possible choice is to expand R2spec in scope and not only create rpm
spec files but to discover the different dependencies and how they are solved
inside.


There is no reason that we can not rebuild the whole CRAN (or almost all of
it) automatically.


R2spec [1] can handles the generation of spec for R-libraries pretty
easily, but the spec always needs some revision behind.


However, I had started some time ago a small script to update the spec
file when there is a new release of an already package R-library. This
might be something that I should develop maybe a bit more now
(especially since Bioconductor 2.3 has been released with R 2.8.0)


Should that be included in R2spec or in a separate tool ?




In the long run, linux distros should look at devising ways to capture
information from these
3rd party package managers to help resolve dependencies automatically.


As everything with free software the survival of the fittest means that this
will only happen if there are people interested in spending resources to make
this possible.


--
For those who do not know it
R2spec https://fedorahosted.org/r2spec
Present in Fedora 8,9 and rawhide (10) and in EPEL 4 and 5.
--

Regards,
Pierre

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-25-2008, 02:04 PM
Warren Togami
 
Default R-devel going away

Tom "spot" Callaway wrote:

This email serves as an announcement that I plan to swallow up R-devel
into the base R package. Why?

* It is causing no end of user complaints. The typical R user expects to
be able to do a "CPAN" (really, I should say "CRAN") style package
install through the R interface:



Isn't this exactly counter to the logic behind splitting perl into
perl-devel, that ended up angering jpo to the point of him quitting Fedora?


The rest of this explanation seems to make sense. But does this mean we
make a mistake earlier in the perl split?


Warren Togami
wtogami@redhat.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 10-28-2008, 07:52 AM
Jeroen van Meeuwen
 
Default R-devel going away

Tom "spot" Callaway wrote:

On Thu, 2008-10-23 at 16:34 +0200, Enrico Scholz wrote:

Better solutions:

* add it to comps.xml
* move 'R' to R-core, and add 'R' which depends on 'R-core' +
'R-devel'



* The size of the R-devel is tiny, about 440K installed.

You miss its dependencies:

(...snip...)


These are very good points, thanks Enrico. What would people think about
doing the suggested R/R-core/R-devel split instead? Users would still be
able to get everything with yum install R, it would meet the guidelines,
and minimal installs with R can simply have R-core.



Big-time R user and I like this plan. +1

Kind regards,

Jeroen van Meeuwen
-kanarip

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 11:16 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org