Innocent question, I have on my julia session:
Version 0.3.0-prerelease+1641 (2014-02-19 18:31 UTC)
_/ |\__'_|_|_|\__'_| | Commit 7812ecd* (43 days old master)
|__/ | x86_64-suse-linux
Which says it has 43 days old master. How can I update my julia installation? I went through the docs and couldn't find what to do except for ubuntu, which I don't need it since I use archlinux. Pkg doesn't do what I want since this is for installed packages, not to update my julia version.
There are two ways to install up-to-date Julia: snapshots builds and building from source
(How did you install Julia in the first place?)
Related
On Ubuntu in a Conda environment with Python 3.7.3, when I run
conda install -c conda-forge opencv
I get OpenCV 3.4.2 (checked with import cv2 and then cv2._version__) even though https://anaconda.org/conda-forge/opencv indicates version 4.11. Why?
Note that I didn't have OpenCV installed previously (I ran conda uninstall opencv and it got completely removed)
tl;dr You likely have previously installed dependencies that need updating. If you require a specific version, say 4.1, then express this to Conda:
conda install -c conda-forge opencv=4.1
Explanation
How Conda Interprets Specifications
A literal translation of the command
conda install -c conda-forge opencv
would go something like
With the conda-forge channel included, ensure that some version of the package opencv is installed in the currently active environment.
The logic here implies that any version it can install would be a valid solution. It also doesn't tell it that it must come from Conda Forge, only that that channel should be included.1
Two-Stage Solve Strategy
Starting with v4.7, Conda uses a two-stage dependency solving strategy. The two stages are
Solve with an implicit --freeze-installed|--no-update-deps flag. This attempts to find the newest version of the requested package that has no conflicts with installed packages. That is, it considers any installation of the package, no matter the version, to be a satisfactory solution. If it works, then it's done. Otherwise, move on to...
An unrestricted solve (what used to be default in Conda < 4.7). This frees up dependencies to be updated and will often result in the latest versions being installed unless there are previous explicit specifications on those packages.2
This strategy aims to provide a faster solve and install experience, by avoiding having to change anything in your environment. It also helps keep the environment stable by avoiding unnecessary version changes.
Specific Failure in Question
What happened in OP's case? One of the dependencies requirements of OpenCV was likely newer in v4.1.1 than what was already installed, but that dependency's version was compatible with installing OpenCV 3.4.2. Hence, the only thing that would change was adding opencv plus missing dependencies. Technically, this is a valid solution since one only asked for some version of opencv to be installed.
Getting the Latest Version
Option: Specifying the Version
If you know you want a specific version then you can always specify it
conda install -c conda-forge opencv=4.1.1
and since Conda can't install this without updating something in your env, the first round of solve will fail, and the full solve will get it for you.
Option: Skip the Freeze
Of course, you may not always know what the latest version number is and don't want to have to look this up on Anaconda Cloud every time. Fortunately, there is the --update-deps flag that essentially skips over the first solve stage and goes straight to the full solve. This will install the latest version for your system, as well as update any of the dependencies.
conda install --update-deps -c conda-forge opencv
Important Note: The --update-deps flag has a side-effect of converting dependencies to explicit specifications. While this is an internal environment state (managed through <env>/conda-meta/history), it does have some behavioral consequences (bugs!):
the result of the conda env export --from-history command will subsequently include all packages, instead of just the ones the user explicitly requested in the past
conda remove will not be able to prune dependencies; e.g., if scipy was installed, it would pull in numpy; if only scipy depended on numpy and scipy was removed, normally numpy would also get removed. This wouldn't work after using the --update-deps flag.
[1]: The behavior here depends on the channel_priority configuration option. With the strict setting, conda-forge would be prioritized over other channels; with the flexible setting, it is simply added to the list and the latest compatible version from any channel is selected.
[2]: One can check the explicit specifications of an environment with conda env export --from-history.
I use Debian sid (amd64), rolling updates as often as weekly. I downloaded recently the desktop version 0.99.902 of RStudio from their offical site and issued (as root, of course):
dpkg -i rstudio-0.99.902-amd64.deb
to no avail:
dpkg: dependency problems prevent configuration of rstudio:
rstudio depends on libgstreamer0.10-0; however:
Package libgstreamer0.10-0 is not installed.
rstudio depends on libgstreamer-plugins-base0.10-0; however:
Package libgstreamer-plugins-base0.10-0 is not installed.
Newer versions (1.0-0) of these 2 packages are installed on the system, but those older ones (0.10-0) are not available anymore on the official Debian repos.
What should be done to have RStudio installed and fully operational under
Debian sid? I have, of course, installed R debs, from official Debian
repositories, without any issues...
Thanks for any help!
RStudio 1.0.153, released on July 20th 2017, depends on GStreamer 1.0 instead of GStreamer 0.10. It can be installed on modern Debian/Ubuntu without any additional setup, rendering this question and my answer obsolete.
To be more specific, there are two different DEB packages. One is aimed at Ubuntu 16.04 (or later) and Debian 9 (or later), comes only in 64-bit flavor and depends on newer GStreamer 1.0. Another package supports Ubuntu from 12.04 up to 15.10 and Debian 8 and it comes in both 32-bit and 64-bit flavors. This one still depends on older GStreamer 0.10.
Original answer remains below.
As of mid-2016, RStudio has hard dependency on GStreamer 0.10 and there is no way around it. You have to install libgstreamer0.10-0 and libgstreamer-plugins-base0.10-0 to use RStudio.
These packages can be easily pulled in from Debian Jessie (stable). Just add Jessie repository to your sources.list and use apt-pinning to give it lower priority:
# /etc/apt/sources.list:
deb http://httpredir.debian.org/debian jessie main
# /etc/apt/preferences.d/01_release:
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 600
Package: *
Pin: release o=Debian,n=jessie
Pin-Priority: 10
Then issue apt-get update and follow up with apt-get install libgstreamer0.10-0 libgstreamer-plugins-base0.10-0.
If you have happened to put RStudio .deb file into local repository, then use apt-get install rstudio and GStreamer0.10 will be pulled in by dependency resolver. This has additional advantage of marking these libraries as automatically installed - they will be subject to automatic removal once RStudio drop them as dependency.
But will that break my system?
No.
Upstream developers designed GStreamer0.10 and GStreamer1.0 as co-installable and able to run at the same time (source). In fact, both were available in Debian repository since September 2012 up to April 2016.
In this pinning setup, packages from Jessie repository will be pulled in only when Jessie is the only provider of requested package. There is no risk of overwriting any package from unstable with older version from stable.
Why does RStudio depend on obsolete library?
Because GStreamer0.10 is the newest version available in both Debian Jessie and Ubuntu 12.04, two distributions they want to support.
RStudio will eventually have to upgrade their dependency to GStreamer1.0, as it will gradually become the only version available. I guess this change may be introduced in spring 2017. First, support for Ubuntu 12.04 will end in April. Rstudio is likely to bump base system requirement to 14.04 - one that has both GStreamer0.10 and 1.0. Second, Debian Stretch - that will have only GStreamer1.0 available - is expected to be released around that time.
I found Miroslaw's answer to be excellent. But, due to the passage of time you will need one more package: libssl1.0.0, so your setup apt-get will look like
apt-get install libgstreamer0.10-0 libgstreamer-plugins-base0.10-0 libssl1.0.0
Download libgstreamer0.10-0 for your machine from any of the mirrors.
Open terminal in the directory where the file is downloaded.
Install it using the command, sudo dpkg -i file.deb. Example sudo dpkg -i libgstreamer0.10-0_0.10.36-1ubuntu1_amd64.deb.
Now open the directory where rstudio.deb is located and install it in the same way.
Download the libraries
http://ftp.br.debian.org/debian/pool/main/g/gstreamer0.10/libgstreamer0.10-0_0.10.36-1.5_amd64.deb
http://ftp.br.debian.org/debian/pool/main/g/gst-plugins-base0.10/libgstreamer-plugins-base0.10-0_0.10.36-2_amd64.deb
Install them with gdebi or dpkg -i and that is it
I'm convinced that using Dirk's package is the best way to install and maintain R on an Ubuntu system. But I want to have some fun and get used to installing R from source.
What are the most common configure flags to use when installing?
Also, if I want to install 2.14.1 and I have 2.14.0 currently installed (which was installed from source), should I first uninstall 2.14.0?
There was a recent thread somewhere about having several versions---one from the apt-get repo, one in /usr/local. Try to find that...
Otherwise, I will roll up 2.14.1 on Friday morning, Michael will do his magic and the repo will have .deb packages of 2.14.1 'real soon', sometimes within a day.
Lastly, you can see which flags are used by getting the package sources for which you just do apt-get source r-base (and that works for any Debian/Ubuntu package that way if you have source references in apt's file.
Edit: By the way, regarding the '64-bit' aspect of your question: Nada. We don't do anything differently. It is "merely" the host OS being more generous with resources. But R finds all it needs to know on its own via its configure etc logic.
My R version is 2.7.1 (on Debian) and some packages are asking for > 2.10. I cannot find updating instructions and I don't want to remove and reinstall as I have other things depending on R and I don't want to mess up. Is there an update procedure?
Closest thing to my problem is on this thread.
check out the instructions for installing from source. Its easy on a Linux box, and you can do the install in any directory you like, you dont even need superuser permissions. Once compiled you can even run R from that directory without messing up any system-installed R. As long as you give the full path to R's binary, or put the path to it in your PATH environment variable, when starting it it will work fine.
FYI
It seems that R on Debian with versions previous to 2.7.1 cannot be updated.
The current core runs from 2.7.1 up. The only way to do it is to remove the existing version.
As this was not straight forward I post it here. If you have Rapache or other things connecting to R disable them with dismode or related.
apt-get purge r-base r-base-dev
I had to do this as well
dpkg -P r-base-core
until this shows no more installed R packages
dpkg -l r-*
Then follow the instruction from http://cran.r-project.org/bin/linux/debian/, with the amendment that you should use deb instead of deb-src in /etc/apt/sources.list.
deb http://<favorite-cran-mirror>/bin/linux/debian lenny-cran/
Before installing run this and it should not say 2.7.1.
apt-cache policy r-base-dev
When installing R packages (say mcmcpack in this example) under Ubuntu I have the choice between the following two methods of installation:
# Let the distribution's packaging system take care of installation/upgrades
apt-get install r-cran-mcmcpack
# Let R take care of installation/upgrades
install.packages("mcmcpack")
Questions:
Is any of the two ways of installing R packages considered "best practice"?
Assume that I first install.packages("mcmcpack") and later on apt-get install r-cran-mcmcpack - should I expect trouble?
Assume that I first apt-get install r-cran-mcmcpack and later on install.packages("mcmcpack") - should I expect trouble?
Update (some thirteens years later): It is now as easy as it seems if you use for example the wonderful and powerful r2u system I set up last year, and which now provides over 20k binary .deb packages for each of twi Ubuntu LTS releases (currently: 20.04 and 22.04), and is also accessible via install.packages() thanks top bspm. Follow the link to r2u for more.
It's not as easy as it seems.
apt-get update is good if and when
packages exist -- but there are only around 150 or so r-cran-* packages out of a pool of 2100+ packages on CRAN, so rather sparse coverage
packages are maintained, bug free and current
you are happy enough with the bi-annual releases by Ubuntu
install.packages() and later update.packages() is good if and when
you know what it takes to have built-time dependencies (besides r-base-dev) installed
you don't mind running update.packages() by hand as well as the apt-get updates.
On my Ubuntu machine at work, I go with the second solution. But because the first one is better if you have enough coverage, we have built cran2deb which provides 2050+ binary deb packages for amd64 and i386 --- but only for Debian testing. That is what I use at home.
As for last question of whether you 'should you expect trouble': No, because R_LIBS_SITE is set in /etc/R/Renvironment to be
# edd Apr 2003 Allow local install in /usr/local, also add a directory for
# Debian packaged CRAN packages, and finally the default dir
# edd Jul 2007 Now use R_LIBS_SITE, not R_LIBS
R_LIBS_SITE=${R_LIBS_SITE-'/usr/local/lib/R/site-library:\
/usr/lib/R/site-library:/usr/lib/R/library'}
which means that your packages go into /usr/local/lib/R/site-library whereas those managed by apt go into /usr/lib/R/site-library and (in the case of base packages) /usr/lib/R/library.
Hope that clarifies matters. The r-sig-debian mailing list is a more informed place for questions like this.
I'd consider using apt-get best practice since you will get automatic updates through the standard system tools.
Having 2 versions installed might get you into confusing situations: depending on your R setup you could load another package version then you expect -- your private (maybe outdated) one should in general be loaded first.
See above.