Building Packages for the VL Repository

(This HOWTO has been copied from a VL forum post)

This is a repost of LLL's post from the old VL forum. The points in it are geared toward VL 5.8. I've taken liberty to update, add and subtract where appropriate.

Cheers,
John

==============
STOP! Wink

BEFORE YOU GO TOO FAR, SEE HOW LONG THIS HOW-TO IS, AND GIVE UP…
1) You likely already have a lot of the skills/knowledge outlined below.
2) If you don't: The details are there for you!
3) Anyone can do this; it's been written by a newbie, for a newbie.
4) If you have questions: post them below!


THE BASICS:

A very basic conceptual understanding of what we're about to do:
Get Source Code —> Configure it —> Compile it —> Package it —> SHARE IT!

THE DETAILS:

A) PREPARE THE HOST (AKA 'YOUR SYSTEM')

1. Clean that box! The development box (or partition) should be as clean as possible, meaning that it doesn't have any veclinux-current, slackware-current or freerock (or other) gnome packages on it. The reason behind this is that we don't want to force dependencies that could cause breakage.

Notes on using a Virtual Machine as your host: Here and here.

2. No OOo! For a similar reason, a build environment should not have OpenOffice as part of it. OpenOffice tends to include symlinks to standard libraries. If a Vector packages is built and OpenOffice is on the box, OO will become an unneeded dependency.

Suggestion: If you have a free partition, perform a clean install of Vector Linux Standard 5.1; make no changes - save this 'install' as your packaging station. If you can't sacrifice the hard-drive space, just keep your system as clean as possible; if your packages aren't working due to a 'dirty' system, we'll find out in testing Wink

3) Set your environment. Put the code below in your $HOME/.bashrc (that's the hidden file called '.bashrc' in your home directory!); doing so sets your system to create packages optimized to VL-standards.
Code:

export CFLAGS="-O2 -mtune=i686 -march=i586"
export CXXFLAGS="$CFLAGS"

Interested in knowing more about compiling flags?!

B) GET THE SOURCE!

1) Download the source code of your choice from the software homepage. Source code typically comes as *.tar.gz or *.tar.bz2 files (the latter has better compression = smaller download for you!).

2) Check for any dependencies listed in the application's docs/on the web. Install them if necessary (using existing packages - e.g., linuxpackages.net - or by compiling them from source…keep reading!). If you have to install/package any dependencies, you will need to share those in the VL-repository as well.

Notes on dependencies (found in the posts below, linked for ease of use):
- 'Dependents'
- 'Suggests'

C) COMPILE & PACKAGE

Open a terminal or command-line interface of your choice; any time this guide asks you to 'Type…', do it in the terminal!

1) Unzip/tar your source code file
Depending on the file you downloaded, use:
Code:

tar xzvf filename.tar.gz

-or-
Code:

tar xjvf filename.tar.bz2

- Move or 'cd' into the new directory (likely of the same name as the file you downloaded)
- Check for an 'Install' or 'Readme' in that folder and read it! Then…

2) Configure & Compile
a) Software Options:
Many software-specific compiling options can be found by typing './configure —help'. For example, when building Sylpheed, you can tell it to be built with spellcheck by typing './configure —enable-aspell' instead of just './configure'. Doing a basic './configure' should, in most cases, just provide the generic program options which should work just fine. The 'readme' or 'install' files may also discuss these options.

b) Installation Location
- You can force the application to be installed in a particular location; on VL, almost every package you create should go to '/usr'.
- How do you tell it to set things up there? With the '—prefix=/usr' option!
- What about apps stored elsewhere?! Not sure where to 'prefix' something to? Guidelines:

Quote from: Someone smarter than me
i) If you are contributing a new package (one not available up to now), use —prefix=/usr.
ii) If you're contributing an updated version of an existing package, check where the old one is installed and use that prefix (most of the time it's /usr sometimes /usr/X11R6, etc.).

Quote from: Kocil

  • About —prefix options

Just to make it tidy a bit
- /usr : for text based applications and libraries
- /usr/X11R6 : for X11 and its immediately related packages, like freetype.
- /opt : for static applications (OpenOffice, Acrobat reader, etc)
- /opt/kde : kde and it's applications
- /usr : XFCE4 and it's applications
- /usr/local : experimental
- /usr/games : games other than those that are KDE-dependent

Now, type:
Code:

./configure (+any options you chose above) && make

For those of you like me who need examples…here's a potential ./configure string for Sylpheed:
Code:

./configure —prefix=/usr —enable-aspell && make

That would set things up to install files in /usr while making spell-check (aspell) available.

3) Setup Checkinstall
- Checkinstall will produce a *.tlz or 'Vector Package' that can be installed/removed via Gslapt or using the 'installpkg' command.
- For effective package building using checkinstall, a description-pak file needs to be created.
- Name it 'description-pak' and save it in the top level of the build directory (i.e., the directory you first cd'ed into way back when/above).
- The description-pak contents are as follows:
Quote from: Kocil
Code:

pkg-name (Description)

The complete description up to [b]9 lines[/b].

Website: http://pkg.sf.net
License: GNU GPL
Author: someone

pkg-name: the correct name of the package
Description: will be shown on VL install, pkgtools or gslapt. Must put it in the () bracket!
Website: VERY IMPORTANT.
License: Check it carefully. GNU GPL is very common. Others include GNU LGPL, Apache, QPL, Sun Public License, BSD, etc.
Author: Please respect the one(s) that make the software in the first place!

Why bother with the description-pak?
- If you don't provide the proper description, VL-Install or gslapt will show "Package created by checkinstall-x.y", which is not so nice.
- Making complete descriptions will also help in the event that someone creates a database of available packages at some point (*hint*) - the database could pull the info directly from the package descriptions.

4) Run Checkinstall
For the final step we need root privileges, so 'su' and type your root password. As root, type:
Code:

checkinstall -L

Quote from: Kocil
USE ONLY VL provided checkinstall that has been patched with slapt-get support. The original checkinstall does not create dependency info by itself. You might setup a manual dependency info by creating files named required-pak, suggests-pak and conflict-pak in the base directory of the package.

D) INSTALL FOR TESTING

Type:

Code:

installpkg software-name.tlz

- After testing, you may remove the package from your host by typing

Code:

removepkg software-name.tlz

E) NAME YOUR PACKAGE

Ensuring appropriate filenames for our packages is a crucial step:
- Why? See Wiki <To be added shortly…>
- As a general rule, Checkinstall will handle the naming for you. In case it doesn't, here's what we're looking for:

NAME-VERSION-ARCH-RELEASE.tlz

NAME: Software Name (e.g., Firefox 1.0.7)
VERSION: Software Version (e.g., Firefox 1.0.7)
- 'Version' must be ONE segment (contains no dashes: '-'). If you have a dash (-), convert it to an underscore ( _ ).
ARCH: i586
RELEASE: 4vl58

The release number needs to be increased if you are rebuilding a package due to packaging errors, the need to incorporate bugfixes in the form of patches, etc. To use the firefox example, if you built firefox-1.0.7-i586-4vl58.tlz and had to rebuild due to an error, the new version would be named firefox-1.0.7-i586-5vl58.tlz. Being consistent with this ensures that the repository maintenance tools will work correctly.

F) SHARE YOUR PACKAGE!

- JohnB316 is our local package repository guru; PM him about uploading your package.

G) ASK QUESTIONS!

- Please…please…if you want to help out, but are stuck on something: ASK! I will gladly be the most patient man ever in helping you along if it means one more happy packager for the VL-community.

AND THAT'S IT…THANKS FOR YOUR CONTRIBUTION! Cheesy
Happy Vectoring!

P.S. Some interesting reading on the history of checkinstall/slapt-get on Vector Linux.

P.P.S: JohnB316 inserted Kocil's additions from his post and noted them as such by using the quote function of phpBB.

======

Some JohnB316 additions to this info:

1) There is some good reading at linuxpackages.net on how to build good packages. I strongly recommend this literature to anybody who wants to do packaging.

2) If you prefer to use checkinstall to do the packaging step (I don't - I personally prefer to use traditional SlackBuild scripts, which I'll discuss in another thread in the future, but I digress), please read the documentation for using checkinstall correctly. You can find the latest README on line here.

3) Be aware that checkinstall will not work in certain situations, like building Mozilla-based applications and other similar apps.

4) There are special considerations needed when building a standalone package to go into /opt. Those will be discussed in a separate thread.

Cheers,
John

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-Share Alike 2.5 License.