You've certainly got some options.
Newer version through Apt?
Ubuntu's main repositories don't provide major upgrades to official packages. They do provide bugfixes and security updates; newer major versions are normally provided in the next major release of Ubuntu (Ubuntu 10.04, aka Lucid, currently in alpha).
You can search the official repositories for the package you're interested in to see what's available, and in what release. Currently, it appears that Karmic is using Gstreamer 0.10.25
, and Lucid currently contains a minor update of the same version. Major updates might be available in Ubuntu's backports
repositories; these are newer packages from later releases that have been built to run on an older Ubuntu release. You may have dependency trouble with these packages, so tread carefully.
You might find a 3rd-party repository that provides a more recent version of Gstreamer, but these aren't officially supported. Good places to look might be Launchpad's PPA system, which are like personal repositories. Add a PPA to your APT repositories list with sudo add-apt-repository ppa:<ppa-name>
.
Backport it yourself?
This is also called "building your own local package". If a newer version of the package you're interested in is available in some repository or PPA but hasn't been built with your version of Ubuntu in mind, you might be better off grabbing the sources and compiling it yourself.
The disadvantage here is that, unless the package is designed to be installed side-by-side with an earlier version of the library, it will probably replace your original system package. The advantage is that the package manager is aware of things, so you can use the package manager to remove the package or upgrade later as necessary, instead of installing whereever you feel the need.
The basic steps are:
- install the build tools;
- install dependencies needed to compile the package;
- grab the package sources (original source tarball, ubuntu/debian patch, and
.dsc
file);
- compile and package.
The automated way (apt-get source packagename
, apt-get build-dep packagename
, etc, see here for more) requires that your APT is configured to access source repositories that has the right version of the package. Since we're backporting a newer version, I prefer the manual route (detailed at the same link): find the package sources (in the Lucid repositories, in the Launchpad PPAs, etc), download them with wget
or Firefox or whatever, then run these in ~/debian-build
:
This untars the sources and applies the patch. (Move the tarball, patch and .dsc
files into the directory first.)
dpkg-source -x foo_version-revision.dsc
Build the package(s). (Check the compile documentation to make sure you've got the necessary build dependencies installed. apt-get build-dep <packagename>
will probably do the trick, but there may be some differences. Mostly, apt-get build-dep
installs the -dev
versions of system library packages that contain header files and such.)
dpkg-buildpackage -rfakeroot -b
Install your new local package.
dpkg -i ../foo_version-revision_arch.deb
Forget the package?
Compile the library/program yourself from the source, without package manager help. No uninstalls, no automated upgrades, just "./configure ; make ; sudo make install
".
This really boils down to two options:
Install to the default location (eg /usr
). Remove the old version from the package manager with apt-get remove <packagename>
or apt-get purge <packagename>
, or just let make install
overwrite the package version.
But... removing a system package without replacing it is asking for dependency problems. It's no fun realizing that APT has uninstalled your desktop manager because you purged one library.
Install to /usr/local
, /opt/<package>-<version>
, or some other location that isn't standard for your system software. That means telling the configure script where to install it.
./configure --prefix=/usr/local
Much better for your system and sanity; your package manager won't surprise you by trying to uninstall your kernel; and your libraries will be installed in a way that you can use one for system purposes and another for testing or compiling.
Handling side-by-side installations?
This depends entirely on what you're trying to do. Let's assume you kept the system package and installed the new version to /usr/local
. New libraries are in /usr/local/lib
, headers in /usr/local/include
, binaries in /usr/local/bin
, etc.
You'd usually access the new version in one of three ways:
- specify on the commandline, one-at-a-time (using shell aliases, or manually specifying);
- alter your shell so the new version is accessed by default (eg, use a shell alias to export altered environment variables so all commands in that shell are configured to get the new version first); or
- tweak the system environment variables so the new version is the system default (use one of the other two options to use the old version).
And it depends on what you're accessing: an executable, a library, etc.
Running a program you installed to /usr/local/bin? Change your environment PATH
so /usr/local/bin comes earlier than /usr/bin, or just give a full path to the binary on the commandline.
Running a program from the system with your new library version? The LD_LIBRARY_PATH
environment variable is a PATH
for dynamic libraries. You can set system defaults in /etc/ld.so.conf
(run ldconfig
after making changes).
For compiling another package, you'd normally pass specific options to gcc
(or make
or ./configure
) to specify the locations of header files ("includes") and libraries, like so (I think...):
./configure --with-gstreamer=/usr/local