Hi all,
Making some packages, and having "some" problems with the dependencies, I was wondering if it possible to increment a sort of R CMD check2 that do all the steps of the R CMD check except the "* checking package dependencies".
That would help to process all the check command and avoid the circular references problem, which is quite common. This command would obviously be used only if the normal command can not be used.
What do you think of ? Is it possible ?
Thanks in advance ~pingou
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
Hi all,
I have just realized that I made a mistake sending my new question instead I send the previous one... My apologizes for that.
Please find here, the original question.
Speaking with some people on the #R chan on irc (freenode) one question shows up, What happened if a library is installed by RPM but was already installed before through the R cmd install command ? Which one of the 2 libraries is used ?
Quite some libraries that I have made are noarch libraries, I install them in /usr/share whereas the r cmd install install them in /usr/lib. Which mean that we can have twice the same library.
Then, I was wondering whether we should include a way to check for the presence of a library before install it.
What do you think of it ??
Other question, in the case that the library has not been installed at the right place should we remove it ? (before install it through the rpm)
Best regards, ~pingou
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
On Thu, Oct 04, 2007 at 01:09:33AM +0200, pingou wrote:
Hi all,
Which one of the 2 libraries is used ?
I guess that R has a search path with both locations?
Quite some libraries that I have made are noarch libraries, I install them in /usr/share whereas the r cmd install install them in /usr/lib.
/usr/share is the right place for noarch libraries.
Then, I was wondering whether we should include a way to check for the presence of a library before install it.
We shouldn't.
Other question, in the case that the library has not been installed at the right place should we remove it ? (before install it through the rpm)
We shouldn't either.
If the user mixes rpm installed and hand installed softwares he should know what he is doing, doing things automatically is not right when we don't know the user intentions.
Now maybe there could be some facilities in R in fedora to help user install his stuff in a specific path (for example /usr/local/lib or /usr/local/share) in order not to install stuff in directories that are traditionnally under rpm conrol, like /usr/lib and /usr/share. But I don't know if it is feasible, nor easy, and I am not sure that it is desirable either.
-- Pat
Patrice Dumas wrote:
On Thu, Oct 04, 2007 at 01:09:33AM +0200, pingou wrote:
Hi all, Other question, in the case that the library has not been installed at the right place should we remove it ? (before install it through the rpm)
We shouldn't either.
Maybe the new feature of R 2.6 could help on that point...
R CMD INSTALL --preclean cleans up the sources after a previous installation (as if that had used --clean) before attempting to install.
Should we use it ? (in the sense that now that R implements it)
Regards, ~Pingou
[1]https://stat.ethz.ch/pipermail/r-announce/2007/000832.html
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
On Thu, Oct 04, 2007 at 12:07:45PM +0200, pingou wrote:
Maybe the new feature of R 2.6 could help on that point...
R CMD INSTALL --preclean cleans up the sources after a previous installation (as if that had used --clean) before attempting to install.
Should we use it ? (in the sense that now that R implements it)
Then R CMD INSTALL --preclean would be called in a pre script or the like? rpm already takes care of removing old files?
-- Pat
Patrice Dumas wrote:
On Thu, Oct 04, 2007 at 12:07:45PM +0200, pingou wrote:
Maybe the new feature of R 2.6 could help on that point...
R CMD INSTALL --preclean cleans up the sources after a previous installation (as if that had used --clean) before attempting to install.
Should we use it ? (in the sense that now that R implements it)
Then R CMD INSTALL --preclean would be called in a pre script or the like? rpm already takes care of removing old files?
I was more thinking to change our command
R CMD INSTALL %{packname} -l %{buildroot}%{_datadir}/R/library
to something like
R CMD INSTALL --preclean %{packname} -l %{buildroot}%{_datadir}/R/library
I have the feeling that it will not solve the problems of the two libraries, but I might help to clean before updated...
~pingou
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
On Thu, Oct 04, 2007 at 12:50:13PM +0200, pingou wrote:
R CMD INSTALL %{packname} -l %{buildroot}%{_datadir}/R/library
to something like
R CMD INSTALL --preclean %{packname} -l %{buildroot}%{_datadir}/R/library
I have the feeling that it will not solve the problems of the two libraries, but I might help to clean before updated...
What is cleaned in that case? Things below
1. %{buildroot}%{_datadir}/R/library
or
2. %{_datadir}/R/library
Or 3. in source?
In case 1. I can't see the interest of doing it, in case 2. it is very wrong, and in case 3. I also can't see what it would be needed for.
Doing it in pre script may have more sense, but once again the user should do it by hand, it shouldn't be automatic.
-- Pat
Patrice Dumas wrote:
Doing it in pre script may have more sense, but once again the user should do it by hand, it shouldn't be automatic.
Then I believe that we should just leave things as they are now :)
___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com
r-devel@lists.fedoraproject.org
-
Patrice Dumas -
pingou