Wed Feb 28 14:42:19 2024 UTC
Cards: The Package Manager
Re: Extremely slow download speed
Sun Feb 25 23:31:04 2024 UTC
Cards: The Package Manager
Extremely slow download speed
Sat Feb 24 03:36:33 2024 UTC
Re: Shutdown issues
Sun Feb 18 19:09:11 2024 UTC
Re: Shutdown issues
Sun Feb 18 12:29:38 2024 UTC
Re: Wireguard Package Request
Sun Feb 18 11:03:40 2024 UTC
Re: Shutdown issues
Sat Feb 17 19:58:32 2024 UTC
Re: Shutdown issues
Sat Feb 17 11:02:14 2024 UTC
Re: Shutdown issues
Sat Feb 17 04:58:06 2024 UTC
Shutdown issues
Wed Feb 14 06:37:03 2024 UTC
Re: Wireguard Package Request [SOLVED]

Thu Mar 7 10:47:45 2024 UTC

How to build a first package

Why should you contribute?

Today NuTyX has about 1,700 applications available in binary form. In one sense, that's a lot. But it really isn't when you consider that new programs are released on the net every day, many under open source licences.

It's clear that you will never see all these programs ready for installation on NuTyX. Just using the github web site, we can find more than 52,000,000 repositories for all platforms.

If you find the application of your dreams, you will have to find all the dependencies, compile it yourself, install it and make it work on NuTyX. That is why we are asking you to contribute a little bit. It is you who will build the package... if you want to of course.

Building an application is often something like:

  • Find an application not available in NuTyX.
  • Download the source code of the application.
  • Check the MD5SUM (strongly recommended but not always possible).
  • Extract sources into a working directory.
  • Enter this working directory.
  • Check that all the dependencies of the package are installed in NuTyX (otherwise the build will not succeed).
  • Type the three magic commands (in most cases; there are exceptions):
./configure --prefix=/usr
make install

The "make install" step must be carried out as root.

That's it! Your new program is built and installed on your NuTyX system.

That's one way to do it... but as you can see, there are a few disadvantages:

  • You do not know what files have been installed.
  • You cannot easily get information about the installed package such as its name, version, description, etc...
  • You cannot share the application with another NuTyX installation.
  • This method is tedious because it needs to be repeated whenever there is an update available.
  • Your NuTyX system is no longer really clean, since you have added files that are not tracked by the package manager.

NuTyX has nice tools to help you with the integration of new programs. You will be then able to track them and maintain them. The package manager will treat them like any other NuTyX packages.

I suggest you to have a look at the FAQ to get an idea about the compilation modus under NuTyX.

What do you need to know to build a package?


You don't need to be an experienced programmer to contribute to this project. A rudimentary knowledge of the bash scripting language is good enough. If you have no knowledge of bash, this article will explain the basic principles for creating a recipe without going crazy.

The bash langage is used to edit a recipe and to generate a package from it. The fact that bash is a programming language might seem frightening to some potential users, who might think: "I don't know how to program". There are three reasons why you should not feel scared:

  • Bash is an interpreted language, not a compiled one, which means that the commands you type in at the keyboard (or read in from a file) are directly executed without the need to construct a complete program.
  • The syntax of bash is very simple and intuitive.
  • Finally the recipe and the creation of the binary package from it seldom use the more complex options of the bash language.

So let's start Wink our little course on bash programming.

Declaring a variable

All you need to do to declare a variable is this:


You declare the variable name by using the equals sign, with the name of the variable to the left of the sign and the value mypackage to the right.

Using a variable

So you know how to declare a variable; that's very nice, but how do you get at its content in order to use it?

To extract the content of a variable you use the dollar sign ($) with brackets if required. Both forms are valid:


It is better to use the first form, otherwise if the variable name contains an underscore, it will not be interpreted correctly by bash:

$name # this works ${_name} # so does this $_name # wrongly interpreted and won't work

In order to see the result of this command, I suggest you create a little file containing this code. You can call the file DeclareVar:

echo "The variable name contains the value: ${name}"

Now give the command:

sh DeclareVar
The variable name contains the value: kernel

Variables manipulations

In a recipe, it's often need to create/modify a variable by using an existing one.

The following examples are taken directly from existing recipes.

  • We want to keep the left part of the variable before a given character here '-'
    The basename variable contains "qt6"

  • We want to keep the right part of the variable after a character given here '-'
    The basename variable contains "tools"

  • We want to keep the first two letters of the variable
    The basename variable contains "qt"

  • We want to delete part of the variable, here the string '6-'
    The basename variable contains "qttools"

Using predefined variables in a recipe

When you construct a recipe, you will have access to a whole series of predefined variables.

PKG: Certainly the most often used, this defines the destination folder for the compiled files. This folder then contains the file structure before it is packaged up
SRC: This variable defines the folder where all the source files are extracted. It is therefore very useful when you need to loop through subfolders and then return to the end of the loop to where you started. This is also the variable which defines the current working directory for the main function of the recipe.
MAKEFLAGS: This variable is not used so often. It is initialized in the pkgmk configuration file. Its use is detailed in another article. For the time being, all you need to know is that it allows you to specify the extent of parallel compilation.
There are others, but personally I see no need for them when constructing recipes.

Declaring an array

To declare an array of strings (or anything else), you add parentheses:

source=(firefox.png firefox.desktop)

This array source contains 2 variables: firefox.png and firefox.desktop. The source array from the recipe for the kernel provides a particularly good example:

source=(${_BaseVersion}.tar.bz2 \
	 config_64 config \$version.bz2 \$name/broadcom-wl-kernel3-01.patch \$name/3.2.8.patch \$name/3.4.patch \$name/makefile_compat.patch \$name/bc_wl_abiupdate.patch)

Each line is a variable in its own right and can be accessed using the syntax:

echo "$(source[1])"

You will notice that each variable can in turn contain other variables provided that they have been defined earlier.

Declaring a function

To declare a function is almost as simple. You use parentheses when giving the name of the function; the function code is always enclosed in brackets { etc }. A little example:

build() {
cd $name-$version
./configure --prefix=/usr
make DESTDIR=$PKG install

As you can see, it's very pretty and also contains a minimal recipe (without the variable declarations). Here you can see the essential use of the PKG variable.

What's a port?


A port is a directory containing the files needed for building a package. The command pkgmk will be used to "build" the package, which can be installed afterwards.

This means that this directory must contain as a minimum a file named Pkgfile. The building of the package will be controlled by the contents of this file. It contains all the information necessary to compile and install the package from source.

The name port comes from the BSD world where a port refers to software "ported" to another operating system or platform. In our case, the port is simply the definitions for building a package.

Minimal syntax of a port

The minimum information required for producing a binary are:

  • name: the name of the build package.
  • version: the version of the sources of the package.
  • release: the nth attempt at building the package. Its value will always start at 1
  • source: the address of the sources of the package we want to build.
  • build(): the function which contains the recipe.

A little example with comments:

# Name of the package

# Version of the package

# Release of the package

# Location of the sources of the package to be built

# Recipe for building the package (often uses three standard commands)
build() {
cd $name-$version
./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
make DESTDIR=$PKG install

If you compare this example with an official NuTyX port, you can see that the official one contains more information. We will see this in the next paragraph.

Practical example of a port

The libxfce4util/Pkgfile file

description="libxfce4util, base library for Xfce"

packager="tnut <>"

makedepends=(glib intltool)



build() {

  cd ${name}-$version

  ./configure --prefix=/usr \


  make DESTDIR=$PKG install

If you want to make sure that the build bot is able to compile the package without any problems, it's important to specify all the dependencies needed for the compilation of the package. Dependencies starting from the NuTyX base are always included. Indeed the bot will always build the package by starting from the NuTyX base.

The line makedepends=(...) is used for this purpose. It defines all the needed dependencies for the compilation of the package. Dependencies are separated a spaceLaughing.

Build your first package

[Important] For this package, we won't use an isolated environment named chroot. We will see in another tutorial how to build in isolated environments: It's the only working method if we need to build a package having dependencies.

We have provided the required Know-how, the minimum syntax of instructions and a list of available packages for you to choose from.

Come and join the many participants of all ages and gender, from all over the world, and venture along this exciting road we call NuTyX. We can promise you a rewarding experience as you build your very first NuTyX system, following our (NuTyX) rules Laughing.

We will show you how to build and install a first package in a very straightforward way.

This tutorial explains to you in a very simple way the construction of your first binary package.

They are no prerequisites. This exercise can be done regardless of the state of your NuTyX.

The chosen package is a little text editor which doesn't need any dependencies.

A few explainations

All the available packages under NuTyX use a recipe.

This recipe (Pkgfile) is located in a folder call as the package name which is stored in a collection.

By default, all the collections are under a folder you choose.

The recipe

We create first the folder: the "perso" collection and the folder of the package.

sudo mkdir -p /usr/ports/perso/nano
echo '
description="Text Editor"
maintainer="Nano team"
packager="Fran├žois Perrin francois dot perrin at myworld dot com"



build() {
cd $name-$version
./configure --prefix=/usr \
--sysconfdir=/etc \
--enable-utf8 \
--enable-color \
--enable-multibuffer \
--enable-nanorc \
make DESTDIR=$PKG install
rm $PKG/usr/share/info/dir
}' > /usr/ports/perso/nano/Pkgfile

Install the development packages

get cards.devel

Compile the package

cd /usr/ports/perso/nano
sudo pkgmk -d

Install the package

sudo pkgadd nano1*

The configuration files

The /etc/cards.conf file

This file is always present on a NuTyX installation.

It's a bit like "the spine" of your NuTyX.

The /etc/cards.conf file will reflect the way you use NuTyX.

All the collections that you want to use in your NuTyX can be specified in two ways:

  1. configuration example of cli collection in binaries from a remote server
    dir /var/lib/pkg/depot/cli|
  2. configuration example of cli in local ports
    dir /usr/ports/cli

This file is also responsible for the list of packages you want to keep when you execute the command:

cards base -r
And finally, it specifies which location should be installed.

You can find more information by reading the cards.conf manual

man cards.conf

The /etc/pkgmk.conf file

This file is used when compiling news ports. It specifies all the variables used by the pkgmk command.

Please take the time to read the main page of pkgmk.conf

man pkgmk.conf
Example of /etc/pkgmk.conf file
export CFLAGS="-O2 -pipe"

case ${PKGMK_ARCH} in
		export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
                export CFLAGS="${CFLAGS} -m32"
                export CXXFLAGS="${CXXFLAGS} -m32"
                export LDFLAGS="${LDFLAGS} -m32"
                echo "Unknown architecture selected! Exiting."
                exit 1
# Those settings are typically set for packaging
# without sub packages and only French locations
# They are also the default ones


We are now ready to build our packages. Lets see now what's a collection.

Be the first to comment on this subject.