Skip to main content

Binary vs. Source Packages



Regardless of the package manager you’re using, you have two ways of installing programs on Linux. You either use a pre-built package, or compile it yourself. These days, the former usually wins out by default. There are, however, times when you should consider the alternative.

What Are Binary Packages?

Installing programs on Linux is usually quite different to installing on Windows. Rather than get the installers off a vendor’s website, the files are retrieved from a repository of programs, usually tailored for your operating system.

Files for separate programs are stored in an archive format. This bundles everything into a single file for easy access later. For example, Debian uses the DEB format to store their programs. These bundles are called binary packages.

Installing requires a special program to extract these files and put them onto your computer. That is to say, your package manager (e.g. APT, Yum, and so on). It also does other useful things, such as keep track of what files you have installed, and manage software updates.

Where do packages come from?

All software is written in lines of text called source code. They’re written in specific programming languages, such as C or C++. Generally however, you can’t just bundle that into an archive and call it a package. These lines need to be translated into a language your computer can understand and execute.

This process is called compiling, the end result creating binaries which your computer can run. It’s these binaries that are stored together inside a package, along with other things such as configuration files.

What Is Installing “From Source”?

Compiling source code isn’t just for making packages. In fact, creating such an archive from it is not even necessary. Basically, installing a program “from source” means installing something without using a package manager. You compile the source code and copy the binaries to your computer instead.
Most of the time, you can download a project’s source code from hosting services such as GitHub or BitBucket. Larger programs might even host it on a personal website. The code will usually be zipped up in an archive format (also known as a source package).

What you need to install this kind of archive is unarchive the package and paste it in your machine and most of the time you need to set the Path for the bin folder in order to execute the scripts at your will.

In this case you can find a README file or INSTALLATION file inside almost every archive and these files contain the appropriate instructions on installation. Installation and configuration is mostly based on terminal commands and remember to execute them as root.

Hope you learn something from this article. Thanks.
~ Chathumina Vimukthi
Labels:

Comments

Post a Comment

Popular posts from this blog

Gitlab SSO implementation using Keycloak

  Prerequisites  Keycloak server should be up and running  By default Keycloak will start on http://localhost:8180 To install and configure Keycloak visit www.keycloak.org/docs/latest/getting_started/index.html. Gitlab must be installed locally By default Gitlab starts on http://localhost:3000 To install and configure Gitlab visit https://docs.gitlab.com/omnibus/manual_install.html Environment Gitlab Installed package - gitlab-ce_11.1.4-ce.0_amd64.deb (Omnibus package) Keycloak version - Version 4.2.1.Finalhttps://github.com/ChathuminaVimukthi/Gitlab-SSO-implementation-using-Keycloak SSO Configuration GitLab can be configured to act as a SAML 2.0 Service Provider (SP). This allows GitLab to consume assertions from a SAML 2.0 Identity Provider (IdP) to authenticate users. For this SSO implementation, Gitlab omnibus package is used. But the source package can be used as well. The configuration for the source packge is available on https:/...
Post a Comment
Read more

Test Driven Development

What is TDD? If somebody asks me to explain TDD in few words, I say TDD is a development of tests before a feature implementation. You can argue that it’s hard to test things which are not existing yet. And Kent Beck will probably give you a slap for this. So how is it possible? It can be described by following steps:     1. You read and understand requirements for a particular feature.     2. You develop a set of tests which check the feature. All of the tests are red, due to absence of the feature implementation.     3. You develop the feature until all tests become green.     4. Refactor the code. TDD requires a different way of thinking, so in order to start TDD you need to forget the way you developed code before. This process is very hard. And it is even harder if you don’t know how to write unit tests. But it’s worth it. Developing with TDD has valuable advantages:     1. You have a better understanding of a f...
Post a Comment
Read more