If you have lots of PPAs, you may want to try a graphical "PPA Manager" to make life easier. Scroll down directly to the PPA Manager section for a recommendation.
No, there is no unofficial "PPA" software center for Ubuntu.
One of Ubuntu's primary goals is to be a stable and reliable desktop Linux for the masses. That is why the packages (and specific versions) in the Software Center/official repositories are carefully vetted and checked for stability. The official repositories (with partners, etc.) should be sufficient for the needs of most regular users.
Why? : Software from a PPA should not be blindly installed
In theory, adding even one PPA package, no matter how "trusted" the source, has the potential to break Ubuntu such that it would be beyond the capability of the average user to fix it.
Thus, installing software from a PPA has to be a conscious and considered choice:
- What am I installing?
- Why I am installing it?
- How is it going to affect my system?
Most of the answers of the type you mention -- "add this repository and install" -- WILL address these concerns for the questioner/user; those that don't are quickly edited/downvoted/commented on.
The three-step add-update-install-from-PPA process makes it more likely people will think a little about what they are doing
The "pain" of adding individual PPAs is somewhat like the "pain" of having to use sudo
instead of just being root all the time. Compared to a one-click install of unofficial packages, the terminal-based three-step process increases the chances that the user has given some thought to what he or she is doing.
Updating PPAs can take longer, because they are not mirrored
I agree that updating PPAs often takes longer for many users, because they are hosted only on launchpad.net and not mirrored. Hopefully Canonical is aware of this and is considering some kind of solution. Note that there is no intrinsic (software/design-wise) reason PPAs should take longer to update than any other repository - they have the same structure.
You can always use a PPA manager to make life easier - try Y-PPA Manager!
Managing PPAs from the command-line can become tiring; if you have three or more PPAs, I recommend you consider the Y-PPA Manager utility. You must install it from a PPA (naturally! :-), and is available as:
y-ppa-manager
in ppa:webupd8team/y-ppa-manager
- It lets you search PPAs for a particular package (via Launchpad)
- And other management functions such adding, deleting, purging, etc.
Some screenshots to give you an idea:
Main Window:
Searching all PPAs for "vlc":
Listing all packages in a PPA:
For a true user-contributed "Software Center", try Arch Linux
- Other distributions which have different goals than Ubuntu and are targeted towards users more comfortable/skilled with Linux do have what you want.
- e.g. Arch Linux has a one-stop "unofficial Software Center" - it's called "Arch User Repositories" (AUR)
- Any user can contribute a package, any other user can install it (after building from source), and the community can vote on packages as a sign of trust/helpfulness. Popular, high-voted packages can even make it into their official repositories.
Not packaged for Precise
As you can see on the packages.ubuntu.com
site with a query, this isn't available in Precise (12.04), but only for Quantal (12.10) and newer.
Rather than installing from source, here's how to build your own package from the sources of Quantal.
Manual package build (backport)
This is a very very verbose description - for anyone building a package for the first time.
Install basic packages to build software and packages: build-essential and devscripts .
Go to the source package (gflags
) page at Launchpad: https://launchpad.net/ubuntu/+source/gflags
Unfold the section for "The Quantal Quetzal (supported) 2.0-1" version.
Locate the source package description file (.dsc
extension). At the time of writing this is https://launchpad.net/ubuntu/+archive/primary/+files/gflags_2.0-1.dsc
Copy the link to your clipboard.
Open a terminal and download the source package using dget
:
dget https://launchpad.net/ubuntu/+archive/primary/+files/gflags_2.0-1.dsc
This will fail the first time:
gpg: Signature made Thu 31 May 2012 14:48:41 CEST using RSA key ID 8AE09345
gpg: Can't check signature: public key not found
Validation FAILED!!
Install the required RSA key as in the error message above:
gpg --keyserver keyserver.ubuntu.com --recv-key 8AE09345
Configure the DPKG development scripts to use your GPG keyring:
echo 'DSCVERIFY_KEYRINGS="/etc/apt/trusted.gpg:~/.gnupg/pubring.gpg"' > ~/.devscripts
See Added key, but dget still shows "gpg: Can't check signature: public key not found" for why.
Run the earlier dget
command again. This should now succeed.
Hop into the directory created:
cd gflags-2.0/
Try building the package.
debuild -uc -us
Explanation for the options: unsigned changes file, unsigned new .dsc
file. As you are not redistributing the package, there's no need to sign anything.
This may fail due to missing build dependencies, e.g.:
dpkg-checkbuilddeps: Unmet build dependencies: debhelper
Note this is really system specific.
Install the build dependencies (satisfy all above from the output you get), e.g.:
sudo apt-get install debhelper
Try building the package again:
debuild -uc -us
One directory below, you'll find your packages, e.g.:
$ cd ..
$ ls -al *gflags*.deb
-rw-r--r-- 1 gert gert 108450 Jun 24 18:59 libgflags2_2.0-1_amd64.deb
-rw-r--r-- 1 gert gert 147590 Jun 24 18:59 libgflags-dev_2.0-1_amd64.deb
-rw-r--r-- 1 gert gert 14778 Jun 24 18:59 libgflags-doc_2.0-1_all.deb
Install them:
sudo dpkg -i *gflags*.deb
In case this fails because of binary dependencies not satisfied, run
sudo apt-get install -f
Done!
You can remove or update them any time, like any other package.
The next time you will build any package you will not have to go through all the hoops... in general the recipe is like:
dget <.dsc-file>
cd thefolder
debuild -uc -us
sudo dpkg -i ../*somepattern*.deb
Best Answer
No, it will not be possible.
apt-get
works with the repositories that are defined insources.list
, as the software center does.You'll find this kind of "layered" systems in many places in linux. To illustrate this, let's look at how an application is installed "low level". To install an application, several (in most cases, many) applications need to be copied to several (or many) different directories. The executable file needs to go to one directory, some libraries need to go to another directory, some manuals (man pages) need to go to yet another directory, some icons need to go to still another directory, and so forth. When you want to deinstall the application later, you'd have to "tidy up" all those files in all those different places.
To make this easier, there's the package manager
dpkg
. A deb package (named this because it was originally developed for Debian, which Ubuntu is based on) is, more or less, an archive that contains files with the information where those files should go. When you install a package, the files are copied to the appropriate places; when you deinstall it, the files are removed. To do this, the "usual", low level tools like for exampletar
are used. This illustrates the concept:dpkg
uses what is already there to simplify a task.Additionally, a package mostly has dependencies. A package can say, "if you want to install me, you need to install this other package as well, because it contains files I need". Or, "if you want to install me, you can't install this other package, because our files would conflict". Again, there's an additional layer on top of "copy some files to the right directories", that uses what's already there.
The next question would be, where do I get those packages? This is where the next layer comes in, the apt tools (
apt-get
,apt-cache
and so on). With apt, you can manage package sources, so called repositories, where it can automatically fetch packages. A repository can be on a server somewhere in the net, on a CD or DVD, on your local hard disk and so forth. Which repositories are available is defined insources.list
. From these repositories, the apt tools build a cache, which is essentially a list of the packages that are available from the repositories.So if you install a package with
apt-get
, it is fetched from the respective repository and handed todpkg
.dpkg
, in turn, installs the package like described above, with tools liketar
.In the next layer, there are GUI tools like Synaptic or the software center. They offer the possibility to manage your packages with a graphical interface instead of "only" on the command line. The GUI tools "under the hood" hand the work over to the apt tools, which (as described) use
dpkg
, which uses tools liketar
. So,apt-get
can't possibly know about any repositories the software center doesn't know about. In fact, it's the other way around: The software center works "on top" of apt's cache, so it can only know about the repositories that are defined insources.list
.The description above can of course only be an outline, with many details and additional features of the respective layers omitted. For example, there's the
sources.list.d
directory in which additional repositories can be defined. They, of course, apply to the apt tools as well to GUI tools like the software center. Another example, the software center not only offers to manage your packages with a graphical interface, but offers the possibility to sell and buy packages as well.