Ubuntu Repository

Introduction to Repository

If we have been a macOS and/or Windows user to date, we are probably finding a program over the internet (often provided in an executable installer) and needing to download and install it. We are probably used to software distributed on DVDs, CDs, etc., which have the autorun aspect from where we can install them. There is a few software distributed this way for open and free systems like Ubuntu Linux/GNU, but those are mostly closed and proprietary programs.

On many systems, such as Ubuntu, almost every software is packaged in good .deb files, which include the libraries and programs we need. These types of files can be downloaded or offered on CDs. Repositories can be described as servers that include groups of packages. Generally, we access them using tools such as Synaptic.

• The tools can mention every package we have installed (through our kernel to our favorite application with every in-between library) and packages that are present in the repositories that we have set up the tool to access to.
• Also, they let us find simple things, such as "image editor".
• The tools offer a centralized and simple technique of software installation and provide the distributors (who configured the repositories) with a centralized path to transfer updates to our software.
• Generally, we wish to have at least the repositories of Ubuntu (which may contain the install CD), but it's not to have other repositories set up in Ubuntu.
• It is important to understand that almost every tool we will wish to utilize in Ubuntu is already in the repositories of Ubuntu.
• We can visit and browse the internet for source code and packages, but almost every time, it will be hard to install and integrate with a system.

Components of Ubuntu Repository

Software in the repository of Ubuntu is categorized into four different components or categories- main, universe, restricted, and the multiverse.
Almost all people will utilize the Ubuntu Software Center for installing the software they wish. But if we are interested in knowing more about the distinct types of software we add, we can continue with the article.

Software is unified according to the capability to handle it and by how nicely it meets the aims of software philosophy at no cost. We can install extra software using the Ubuntu Software Center. The classic Ubuntu installation is a set of software from the restricted and main components.

Main

This component includes applications that are freely available software, can be distributed freely, and are completely supported by the team of Ubuntu. It contains the most reliable and famous open-source software available, several of which are added by default when we install Ubuntu.

In main, the software contains a hand-selected application list that the Ubuntu users, community, and developers feel are most crucial and that the Ubuntu distribution and security teams are wishing to support. When we install software using the main component, we are assured that the application will be offered with security upgrades and technical support is present from Canonical.

Universe

It is a snapshot of the Linux, open-source, and free world. It contains most parts of the open-source application, each created from a variety of public sources. Canonical doesn't offer an assurance of continuous security updates for applications in this component but will offer these in which they are available via the community. People should know the risk acquired in utilizing these packages. A well-supported or popular part of the software will shift into main from the universe if they are returned by maintainers wishing to match the standards determined by the Ubuntu team.

Restricted

To commitment of the Ubuntu team is only to promote open-source software- or software present upon a free license. Although, they make exceptions for a narrow set of drivers and tools that make it feasible to install Ubuntu and its no-cost software on regular hardware. These fixed drivers are kept in this component.

Note: It might not be possible to offer full support for this application because they are not available for fixing the software- they can only forward the issue to the actual authors.

From the restricted component, a few software will be there on Ubuntu CDs but separated to make sure that it's easy to delete.

They will only utilize non-open-source applications when there is no other path for installing Ubuntu. The team of Ubuntu operates with vendors for accelerating the open-source aspect of their application to guarantee that as much application as possible is present upon a free license.

Multiverse

This component includes software that's not free, which defines that the licensing needs of this software don't match the license policy of the Ubuntu main component. The blame is on us to verify our rights to utilize this software and adhere to copyright holder licensing terms. This software isn't supported and can't usually be updated or fixed. We need to use it at our risk.

Why do we use PPA?

Ubuntu, more importantly, controls which release of software and what software we get on our system. But suppose if a software developer publishes a new software version, Ubuntu will not make it immediately available. There is a process to inspect if the new release of the software is suitable for the system. It ensures system stability.

But it also defines that it will be in a few cases, or a few weeks, a few months before it's made present by Ubuntu. Everyone would not wish to wait that long for getting their hands on the fresh release of their favorite software.

Similarly, imagine someone develops an application and wants Ubuntu to add that application to the official repository. Again, it will take some months before Ubuntu decides and adds it to the official repositories.

Other cases would be at the time of the beta testing. A software developer may wish a few end users to inspect their next release, even if a stable release of the software is present in the official repositories. How do they let the people beta test the next release? We can utilize PPA.

Working and Usage of PPA

PPA stands for Personal Package Archive. Mind the "Personal" term here. That provides the hint that it's something absolute to a developer and is officially not approved by the distribution.

Ubuntu gives a platform known as Launchpad that let's software developers make their repositories. We can include the PPA repository in our sources.list. When we update our system, our system will be aware of the availability of this fresh software, and we can install it with the help of the standard command, i.e., sudo apt install.

For example:

• sudo add-apt-repository <PPA_info>: It will merge the PPA repository in the list.
• sudo apt-get update: It will update the package list that can be installed on our system.
• sudo apt-get install <package_in_PPA>: It will install the package.

As we can see, it's important to run the sudo apt update command, or else our system will not be aware of a new package being present. The 18.04 and higher versions of Ubuntu automatically execute the update for refreshing the package list. It is a good practice to execute this command.

Now, take a look at the command in a more detailed form:

We will notice that the above command does not contain a URL. It is due to the tool has been created to abstract the details about URLs from us. If we include ppa:dr-akulavich/lighttable, we will have Light Table. We will get all packages or repositories listed inside the "upper repository" if we include ppa:dr-akulavich. It is hierarchical.

When we include a PPA with the help of the add-apt-repository, it will basically do a similar action as if we execute these commands manually:

The two lines which are mentioned above are the classic way to include any repository in our sources.list. However, PPA can do it automatically for us without surprise about the same operating system release and repository URL.

An important thing to remember here is that when we utilize PPA, it does not modify our actual sources.list. Rather, it makes two files in the directory, i.e., /etc/apt/sources.list.d, a backup, and a list file with the "save" suffix. With the suffix 'list', the files have the command that includes the details about the repository. It is a safety measure to make sure that including PPAs does not mess with the real sources.list. Also, it helps in deleting the PPA.

PPA vs. DEB Packages

We may ask why we should utilize PPA when it is utilizing the command line, which may not be approved by everyone. Why not only share a DEB package that could graphically be installed?

The answer ranges in the update procedure. If we install an application with the help of a DEB package, there's no assurance that the installed application will be updated to a fresh version when we execute the sudo apt update and sudo apt upgrade commands.

It is due to the apt upgrade process ranges on the sources.list. It does not bring the update by the traditional software updater if there's no entry for an application.

Does it mean an application installed with the help of a DEB package never brings an update? Not really. It relies on how that package was made.

A few developers include an entry in the sources.list automatically, and it's updated like a normal application. One such example is Google Chrome.

A few applications would notify us of the availability of a fresh version when we try to execute it. We will need to download a new DEB package and execute it again for updating the current application to a fresh version. In this case, an example is Oracle Virtual Box.

We will need to search for an update manually, and it's not convenient, especially if our application is defined for beta testers. We need to frequently include more updates. PPA plays its role at this time.

Unofficial PPA vs. Official PPA

Also, we may hear the unofficial PPA or official PPA terms. But what is the difference between these two?

When developers make PPA for their application, it's called an official PPA because it's coming from the project developers. On the other hand, individuals make project PPA that were made by other developers.

But why will someone do it? Because several developers just offer the source code of the application, and we know that it is complex to install any application from source code in Ubuntu, and not everyone would or could do that.

So, volunteers take upon themselves to make a PPA from these source codes so others can easily install the application.

Ensure that PPA is available for our distribution version

There are some things we should remember when it comes to utilizing PPA in Linux or other distributions.

All PPAs are not available for our specific version. We should understand which version of Ubuntu we are using. The version codename is essential because when we visit a certain PPA webpage, we can find which version of Ubuntu is supported by PPA.

We can find the /etc/os-release content for finding out the information of the specific Ubuntu version. We can also find out the URL of a PPA. We simply need to find on the internet using the PPA name, such as ppa: dr-akulavich/lighttable, and we should bring the initial result from the website of Launchpad, the official environment to host PPA. Also, we can visit the Launchpad and find the needed PPA there directly.

If you do not verify and include a PPA, we may find an error such as the following when we try to install an application not available for our version.

What is worse is that it has been included in our source.list; every time we execute the software updater, we will face the "Failed to download repository information" error.

If we execute the sudo apt update command in the command line, the error will contain more information about which repository is giving the trouble. We can see something like it in the completion of the result of the sudo apt update command.

It is self-explanatory due to the system can't find the repository for our version. Keep in mind what we saw previously about repository structure. APT will attempt to search for the application information inside https://ppa.launchpad.net/<PPA_NAME>/ubuntu/dists/Ubuntu _Version. And it will never be capable of accessing the URL, and we get the popular 404 error if the PPA for a particular version isn't available.

Why is every PPA not available for every Ubuntu version?

It is due to someone is needing to compile the application and make a PPA out of it on the particular version. Seeing that a fresh Ubuntu release is published every six months, it is a tiresome operation for updating the PPA for all Ubuntu releases. Not every developer has enough time to do it.