Project

buildozer

0.0
No commit activity in last 3 years
No release in over 3 years
Buildozer is an application that aims to ease the building and packaging of software. With this application, and with the help of the fpm library, you should be able to build and package any software like a breeze in a fully automatic manner.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 10.0.3

Runtime

~> 0.4.29
~> 0.17.0
 Project Readme

Buildozer

Buildozer is an application that aims to ease the building and packaging process of software.

With this application, and with the help of the fpm library, you should be able to build and package any software like a breeze in a fully automatic manner.

Installation

Use this command to install buildozer:

gem install buildozer

Versioning

A small note about versioning of this project. Backward compatibility for users will be kept for major version. That means that your definition files are guaranteed to work for version 1.y.z. The day we release 2.y.z, it will not be backward compatible with major version lower than 2.

Internal representation will be backward compatible for minor version. That means that if your are using buildozer as a library, you can follow x.1.z whitout fear of breaking your code. However, changing from x.1.z to x.2.z will likely requires changes on your part.

Finally, new additions and changes that are backward compatible for users and developers will be made on the revision version. For example, x.y.3 will be compatible with x.y.4.

Usage

The meats that feeds every buildozer command is the definition. The definition file (always ending with .bd.rb) is defined using a custom DSL based on ruby that ease packages definition. Each definition can contains 0 to N packages.

For each package, you defined some basic information about it like the name of the package, it's version, the url where sources can be found and many others including what the package provides and its dependencies.

For now, each definition if more or less platform specific but I hope this will change overtime to have platform agnostic package definition.

Here a sample build definition for erlang (Important note, the build definition is fake for now, will update it with real stuff at some points):

# Buildozer package definition
#  Architecture: x86
#  Platform: CentOS 5.9

package "erlang" do
  url "http://www.erlang.org/download/otp_src_R15B03-1.tar.gz"
  version "R15B03"
  maintainer "Matthieu Vachon"

  architecture "i686"

  provides "erlang"

  depends "libc.so6"

  includes "usr/bin"
end

package "erlang-devel" do
  url "http://www.erlang.org/download/otp_src_R15B03-1.tar.gz"
  version "R15B03"
  maintainer "Matthieu Vachon"

  architecture "i686"

  provides "erlang-devel"

  depends "libc.so6"

  includes "usr/include"
end

A definition can contain multiple package definition. This is useful to define at the same time normal package and a development package. In the future, we plan to reduce duplication of package information maybe be specifying a inheritance mechanisms, ideas are welcome :)

Here the list of valid options for a package

  • url - The url where the package can be downloaded.

  • version - The current version of the package

  • maintainer (optional) - The name of the maintainer of this package. This is NOT the author but rather the one who build the package.

  • architecture (optional) - The target architecture of the package. If left blank, the architecture of the machine is used. If set, it must be :auto or a non-empty string value.

  • provides - An artifact that the package provides. Usually, this is binaries and libraries generated by the package when built. This can be call multiple times, each time adding a new provided artifact.

  • depends - An artifact that the package depends on. Usually, this will be some libraries or binaries needed to run the package. This can be call multiple times, each time adding a new dependency artifact.

  • includes - A list of folders that will be packaged when building an archive for the package like a rpm. This can be call multiple times, each time adding a new included folder.

Commands

When you have a build definition, let's call it erlang.bd.rb, you pass it to the various commands to do something useful with it.

Command RPM

The command rpm can be used to generate rpms from a definition file. The command will produce a single rpm for each package defined in the definition file.

> buildozer rpm -d "/path/to/built/package" erlang.bd.rb

It is important to note that you will need rpm_build on your machine for this to work. The command will fail if it's not the case.

In its internals, buildozer uses fpm to produce the rpm archive file. You can see the commands that would be executed by doing a dry-run. This will print the commands to the standard ouput instead of executing them.

> buildozer rpm -n -d "/path/to/built/package" erlang.bd.rb

Contributing & Support

To contribute, simply fork the repository, make the changes you want and submit a pull request. Also, you can start an issue without a pull request if you would like some features or you have found some bugs.

You can also creates an issue just to discuss potential ideas and future directions for the project.