1

I have installed GStreamer using the synaptic package manager but I would like to upgrade to a newer version. Package management is something I'm not very familiar with, so here's a few of my questions:

  • Can I ask apt-get to find a newer version for me? Or do I need to download the newest version myself and build from source?
  • If I do build from source, followed by a 'make install', will I then have two different versions on my system?
  • If yes, then how does the system decide which version to use?
  • Can I tell the system to use the old GStreamer for everything, but to use the new GStreamer libs for linking with my code? If yes how?

I am using GStreamer only as an example, I am interested in how these issues are handled generally.

3
  • which version of ubuntu? what version of gstreamer do you have? what version do you need? Dec 11, 2009 at 13:48
  • It's really a general question. Dec 11, 2009 at 14:19
  • yeah noticed that at the end of your post just now... when i looked up gstreamer there really wasn't a newer version. :) Dec 11, 2009 at 14:33

2 Answers 2

2

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:

  1. specify on the commandline, one-at-a-time (using shell aliases, or manually specifying);
  2. 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
  3. 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
    
0

If apt-get can't find a newer version, it may not exist, or you may need to add a repository.

If you build from source and do "make install", you will have a.) two versions, or b.) a blend of versions. Installing to /usr/local/ helps insure you get a.). A better idea would be removing the Apt version.

The shell PATH parameter of your Gnome (or KDE) system is used to determine which application is chosen first.

The simplist way to use both is install the new to /usr/local/, and create a desktop shortcut to use it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .