Mepis Package Building Guide

From MEPIS Documentation Wiki

This is a work in progress for the community to develop acceptable packaging guidelines to assist Warren in developing future Mepis versions.

1 Setting The Environment
2 Documentation
- 2.1 Recommended Reading
- 2.2 Recommended Reading – Web
3 Base Procedure – Packaging for Official Mepis & Community Repos
4 Recommended Package Creation Methods
- 4.1 Basic Package Creation Decision Tree
- 4.2 Details of Each Method
5 Special Notes - IMPORTANT

[edit]

Setting The Environment

[edit]

Environment (Essential)

[edit]

Packaging For Mepis Official Repository

Clean Mepis standard environment – only Debian Stable and MEPIS repositories enabled. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
Due to legal considerations, no packages from the Debian-Multimedia repository can be installed, and the repository must be disabled.
Debian backports repository disabled – they are not always compatible with Mepis

[edit]

Packaging For Mepis Community Repository (main non-free)

Clean Mepis standard environment. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
Due to legal considerations, no packages from the Debian-Multimedia repository can be installed, and the repository must be disabled. For restricted packages - see section imemdiately below.
Debian backports repository disabled – they are not always compatible with Mepis

[edit]

Packaging For Mepis Community Repository (restricted)

Clean Mepis standard environment. A clean VM (eg virtual-box environment) is a good substitute for a clean stand alone install.
If any portion of your OS environment has been upgraded to testing or unstable, you cannot build for standard MEPIS repositories
Debian-Multimedia repository enabled – packages produced for restricted repos will be held on server outside US / other restricted countries.
Debian backports repository disabled – they are not always compatible with Mepis

[edit]

Environment (Recommended)

Clean separate install of MEPIS on a separate test / build partition
Where possible we would like package builders / testers / maintainers to be able to use both 32bit and 64bit architectures.
If your hardware is adequate, Mepis installs in virtual machines are useful in compiling and testing packages.

[edit]

Software (Essential)

Basic build packages:

 apt-get install build-essential devscripts dh-make fakeroot autotools-dev xorg-dev libqt3-mt-dev kdelibs4-dev libqt3-compat-headers

Additional build recommended packages:

apt-get install -f autoconf automake automake1.7 automake1.8 automake1.9 g77 gpc lintian libqt4-dev cmake pbuilder

(Leave out automake1.8 and g77 if using Mepis 8, as the packages are not in the repositories.)

[edit]

Preconfiguration

Add in ~/.bashrc (a hidden text file in your home directory) these environment variables:

export DEBEMAIL=maintainer@mepiscommunity.org

export DEBFULLNAME=�?Your Name�? (use your own name!)

These must be the same as used in creating your public/private keys in gpg or Kgpg.

These variables are used by dh_make when creating debs.

Run in a konsole terminal as a regular user

source ~/.bashrc (~ is shorthand for your home directory)

You will also need to create a public/private key pair. This can be done in the terminal with gpg, or with a user-friendly frontend such as Kgpg, under Keys >> Generate Key Pair. Make sure not to lose your gpg password!

For more information on GPG, and a video tutorial, please see the GPG page.

[edit]

Documentation

[edit]

Base Procedure – Packaging for Official Mepis & Community Repos

Please also refer base procedure in Community Repository

[edit]

Packager (part 1)

Packager starts a thread (or if version update, adds to existing thread) in the News/Package Status forum - advising that they are assigned to building a new package / version update.
Packager uses one of recommended methods (in this procedure) for creating debian package
Following successful deb creation, Packager tests installing the created deb, and if successful, advises their Maintainer of the availability of the completed package - along with sending him/her the necessary files for the repository (the deb(s), dsc, diff, changes and source files).

NOTE: You have to submit the maintainer the ".changes" file for a given package as well as all the files listed in the "Files:" section withing the changes file. For 64 bits packages those files cannot be of the kind "_all.deb". See Special Notes

[edit]

Maintainer (part 1)

On receipt of advice from their packager, the Maintainer downloads the files from the link provided, virus scans them, installs them in a test environment (to ensure working), and if ready for testing, uploads them to the test repository.
Once the package appears in test, the Maintainer contacts their Packager and advises him/her to post in the original ML thread that their package is available in the Test repository, and to request testing and feedback.

[edit]

Testers

Testers (from the community) install debs and commence thorough checking of application.
Any errors / lack of functionality are noted
Following full testing, feedback is given in the original thread on MepisLovers.

[edit]

Packager (part 2)

Packager acts on Tester feedback.
If package fails successful testing with errors or loss of functionality, errors are corrected by Packager, and files resubmitted for testing.
If package passes testing with full functionality, Packager's duties are complete, and Maintainer arranges for final migration of Package from test to main repository.

[edit]

Maintainer (Part 2)

Once package has passed testing and is declared ready for the repository,

Package is either sent to Developer certified as correct and ready for Mepis repositories , OR
If only intended for Community repositories, package and source is purged from test repository and added to main repository.
For Community repository packages, the Maintainer then adds the final post to the original MepisLovers thread confirming that the package is available in the main repository.
The Maintainer also either adds or edits the entry in the Community Packaging Section of the Mepis Community website.
The final step is to add a short 'news' entry on the Community Website that the package has been added to the Community Repository.

[edit]

Developer

If the package is intended for the Mepis main repository:

Developer uploads package to official Mepis repository and notifies Website Maintainer to update Community News section that new package in repo.

[edit]

Versioning

Be sure to reversion packages by simply adding :
- mepis1 to the end of the debian version (for official Mepis Repository) OR
- mlrepo1 to the end of the debian version (for Community Repository)
If the version ends in debian1 or ubuntu1 etc, drop the debian or ubuntu minor version number.
Be very careful not to increase the version number any more than you have to
The number should be higher than the equivalent debian number and less than the most likely next debian number.

Example:

debian: 915resolution 0.53-1

mepis: 915resolution 0.53-1mepis1

next mepis: 915resolution 0.53-1mepis2

next debian: 915resolution 0.53-2

then mepis: 915resolution 0.53-2mepis1

Community versioning follows same pattern except mlrepo instead of mepis.

[edit]

Recommended Package Creation Methods

[edit]

Basic Package Creation Decision Tree

Attempt in the order shown.

1. Backporting From Upstream Debian. The package is in the Debian pool. A newer version is available but not for Debian Stable. In this case, get the Debian source for the newer version and change the maintainer and minor info to MEPIS.

NOTE - unless you are a "debian wizard�? avoid using source from debian 'experimental'

a. Attempt to compile it in Mepis. If this works, great. Time to test and publish.
b. Try to resolve compilation issues. If there are more than 2 levels of issues, this is doomed to failure. But if it works, great.
c. Try a newer, but not quite so new version from Debian that may be more compatible with MEPIS. Look in the Debian snapshots pool if you know exactly what change you're trying to avoid. Maybe even inspect the change that broke compatibility and attempt to reverse it in the MEPIS version of the latest Debian version.

2. Repackaging from Debian-Backports As a fallback, check the backports pool for a Debian Stable version. Again, change the maintainer and the minor version.

a. Attempt to compile.
b. If that fails, attempt to fix the issues, again only go 2 levels deep.

3. Backporting from Ubuntu If still no success, try an Ubuntu version. Source files can be found at packages.ubuntu.com. Be very very careful about introducing Debian incompatibilities. Libraries have often been renamed.

4. Packaging from Bare Source Tarball If there is no Debian packaged good version, try creating a Debianized version from vanilla source. If there is an older Debianized version, try reusing its Debian directory.

5. For packages that are unusual and not normally maintained in Debian, alternately create an installation tree manually and then build the package with dpkg -b.

[edit]

Details of Each Method

[edit]

1 Backporting From Upstream Debian (Recommended Method)

NOTE: I recommend creating a GPG key to sign your packages as outlined above.

Go to http://packages.debian.org and type the name of the package you want to backport into the "Keyword" text input box, and change the "Distribution" drop-down box to "any".
Click the link for the version you want to backport. You can also peruse the Debian changelog to get an idea of what is different between the versions.
On the right-hand side of the page there is a section titled "Links for <packagename>". Download the three files under the sub-heading "Download Source Package". There is normally an .orig.tar.gz, a diff.gz, and a dsc file. Sometimes there may not be a .diff.gz file if the package is a Debian original and not from an upstream source, but everything from here on out is still the same. To download the .dsc, you must right-click and select "Save As", as normally the browser will open .dsc files as a plain text file. Be careful! Often the directories for clicking to save and right-clicking to save as are different. Make sure all files are downloaded to the same folder. I usually use a folder in my /home/username/Source directory titled "DEB-packagename-version".
Open a console and cd to the folder you downloaded to, or navigate to the folder using Konqueror and hit "F4" to open a console at that location.
In the console, type "dpkg-source -x " and then hit the tab key. If there is only one .dsc file in the directory (as there should be), then the filename will be entered automatically. Hit enter to issue the command, and the source should be extracted and patched.
Type "cd " and hit tab. The newly created folder's name should be automatically filled in. Hit enter to change to the source folder.
Type dch -i into the terminal and hit enter. This will open a debian changelog editor in the console with the time/date stamp and your maintainer information already entered (as long as you exported as outlined above in "Setting the Environment"). The debian version of the package will have been incremented, so change it back to the version in the previous entry in the changelog and add the appropriate tag to the end, as follows:
- Mepis version: foo_1.1-1mepis1
  - Community version: foo_1.1-1mlrepo1
  - If it becomes official: foo_1.1-1mepis2
- Mepis version: foo_1.1-1mepis1
  - Community version: foo_1.2-1mlrepo1
  - If it becomes official: foo_1.2-1mepis1
- Mepis version: nonexistent
  - Community version: foo_1.1-1mlrepo1
  - If it becomes official: foo_1.1-1mepis1
Change "unstable" or "testing" to "mepis". After the asterisk, type "Repackaged for Mepis 7.0" (or 8.0, when appropriate). Hit Ctrl+X to begin to exit the debian changelog editor. Hit "y" to save changes. Then hit Enter to save the changes to the same file. This will return you to the command line prompt. This file may have to be edited more later, if anything must be changed in the code or /debian directory to get the package to build.
Type cd debian into the console and hit enter to change to the Debian directory.
Type kwrite control and hit enter to open the /debian/control file in Kwrite. You can use your preferred text editor instead of Kwrite.
Add "Upstream-" before the Maintainer/Uploaders/etc., and make a new line above these that reads "Maintainer: yourDEBFULLNAME <yourDEBEMAIL>", replacing yourDEBFULLNAME and yourDEBEMAIL with the info you exported as outlined above in "Setting the Environment". Save and close the control file.
Type cd .. into the console and hit enter to return to the source directory.
Type dpkg-buildpackage -rfakeroot (if not signing the packages, pass the options "-us -uc" as well; if building for the community repo, also add the option "-sa" to build files necessary for deb-src, at least on the first build of the package) into the console and hit enter to begin building the package. SPECIAL NOTE - if packaging 64b (assuming you or someone else has already built for 32b) substitute -B for -sa (refer special notes section for more explanation). If it errors out with a message about build dependencies not being satisfied, try to install them doing the following, and then issue the command again:
- Type su into the console and hit enter
- Type in your root password and hit enter
- Type /usr/lib/pbuilder/pbuilder-satisfydepends (make sure you have installed pbuilder) This will install all build-dependencies listed in the /debian/control file, as long as they are in the repositories. Note: In Mepis 8, the default behavior of this command seems to be uninstall unused -dev packages at the same time it installs new ones. This makes it difficult to compile two programs at once, which is one use of a multi-core system. Installing aptitude, then issuing this command in a root terminal seems to fix this problem: aptitude keep-all
- If this works, awesome! If something is not found, you may have to look into backporting a new version or even an entirely new package to meet the build-deps. Sometimes the same libraries are provided by different packages under etch and lenny/sid. If this is the case, edit the control file again with your preferred text editor to reflect the package names in Mepis/etch. After this is done, return to this step in the original package.
If you have created a GPG key, after the packages have been built, you will be prompted to enter your GPG key passphrase to sign the ancillary packages.
You should now have all the necessary .debs (and the source, diff, changes, build files) in the top-level folder that contains the Debian source files. Install them as appropriate and test!
Another option is to subscribe to the Sourceforge files RSS or the home page RSS feed of the program, so you know when a new version comes out, and what the changes/advantages are. If there are enough advantages to the new version, you can keep an eye on the Sid package page and wait for an upstream Debian release to repackage.

[edit]

2. Repackaging from Debian Backports

Source packages are also found at packages.debian.org Procedures are the same as in Step 1.

[edit]

3. Backporting from Ubuntu Repository

Get source from packages.ubuntu.com, possibly getdeb.net. Libraries may have been renamed.

[edit]

4. Packaging from Bare Source Tarball

Download source file.
Untar (extract) the source package to your normal test directory.
Go to the unzipped directory and thoroughly read all provided documentation. Pay particular attention to README or INSTALL files. Ensure you install any dependent libs / dev files before starting to configure or compile.
Test the package by locally installing using the basic:
./configure
make
make install (as root)
Certain programs use other methods. Some already have a makefile and just require make, while others need you to first create a configure file with ./autogen.sh (look for this file), or cmake or "cmake ." (cmake period) Qt3 apps in Mepis are configured with qmake, and that can combined with make: qmake&&make . Readme files for QT4 apps will also specify qmake, but in Mepis the correct command is qmake-qt4 . An alternative method is to pass a flag to qmake: qmake QMAKE=qmake-qt4
Make sure it is running properly and doesn't break anything in your system while it's running or installing. Pay attention to the configure output during configuration. Note any errors, or missing functionality.
If package does not configure or make, note errors and correct problems until you can cleanly install and test.
Remove the locally installed package using:
make uninstall (as root)
from the /test/program directory. Following this, run
make clean
or better -
make distclean
to clean up the build directory.
After the testing is over, make notes of the configure procedures required, and extract a fresh copy of the source from the tarball. Enter the root of the source directory (which needs to be named with the program name and version; for example, newprogram-1.2.2) Open a terminal and enter
dh_make -m -n --createorig (Please note that using these switches creates multiple deb files *if required* and will also create an original.tar.gz version of the source - i.e., it follows Debian recommended procedures).

From man:dh_make:

Single binary (s)

The package will generate a single binary .deb package. It is the standard case, so if you don't know what to do, choose this.

Multiple binary (m)

The package will generate multiple binary .deb packages from one source package. Choose this for larger packages that need to be split.

Library (l)

The package will generate at least two binaries. One library package containing just the lib in /usr/lib and another *-dev_*.deb package containing documentation and C headers.

Kernel module (k)

The package will generate a binary-all kernel module -source package for use with the make-kpkg command. It also generates a binary package for additional utilities, daemons, etc. that may come with the source.

cdbs (b)

The package will be built using the Common Debian Build System. CDBS provides a sane set of default rules upon which packages can build.

You will get a display of what's going to be in the new folder, hit enter to proceed. A new /debian folder will be created.
If earlier versions of the package are in the repos, it's often useful to get the source files per Step 1 and obtain the /debian folder from there. If it can not be reused outright with some editing of the versions and maintainer, it can be mined for package descriptions and possible configure tips.
Manually edit the necessary files in the debian directory (where necessary). The most important files to take note of are the changelog, control, rules and copyright files. For further information on editing the files in the /debian directory, it is recommended to read on-line information from the Debian Women Wiki (see links in the early part of this document).
If any unusual commands or flags were necessary to configure, compile, or install the package, they can be added to the rules file. There is a labeled section for each in the file.
Now to configure, make and build deb. Run following command:
debuild
This will automatically run configure, make, and create the deb file. It will also run lintian (if installed) and list any errors.
Test the completed package and upload to maintainer.

Note: This method will create one large .deb file, which will contain the program, its header (-dev) files, documentation, and other parts. Standard Debian practice is to modify the rules and control file as to break these all out into separate debs. If a user tries to update a multi-part Debian package with a single .deb, it may fail. Workarounds include giving advice to completely remove the older parts of the program first, or adding "Conflicts/Replaces/Provides" lines in the control file:

Dependencies:  something, something, something
Conflicts:  package-dev, package-docs, others
Replaces:  package-dev, package-docs, others
Provides: package-dev, package-docs, others

For example, let's say you are going to build a single .deb version of Pidgin 2.4.3. Through a little research, it can be found out that Pidgin used to be called Gaim, and searching for Gaim in Synaptic shows : gaim, gaim-data, and gaim-dev. If some one has those installed, we need to make sure they are replaced.

Conflicts: gaim, gaim-data, gaim-dev
Replaces: gaim, gaim-data, gaim-dev

Through a little more research (mainly by looking at the /debian/control file from the Debian sources), we can see that the stock backports repository version of Pidgin 2.3.1 has been split up into many packages: pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, all of which are going to be included in your single .deb version, so:

Conflicts: gaim, gaim-data, gaim-dev, pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev
Replaces: gaim, gaim-data, gaim-dev, pidgin, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev
Provides: pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev

Also, we can see there is an older single .deb version of 2.3.1 available from the first community repository. To make sure this and any other older versions of Pidgin get replaced, add "pidgin (=<2.4.2)" to the end of the Conflicts and Replaces lines.

Conflicts: gaim, gaim-data, gaim-dev, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, pidgin (=<2.4.2)
Replaces: gaim, gaim-data, gaim-dev, pidgin-data, pidgin-dev, pidgin-dbg, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev, pidgin (=<2.4.2)
Provides: pidgin-dev, pidgin-data, finch, finch-dev, libpurple0, libpurple-bin, libpurple-dev

This should allow for upgrading from Gaim, plus older multipart and single .deb versions of Pidgin.

[edit]

Special Notes - IMPORTANT

[edit]

General

The field "section" in the control file is compulsory. Using "unknown" as section name is not allowed. At present supported sections are: admin, comm, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11. This allows the packages to be properly categorized when using Synaptic.

[edit]

32b / 64b

The ideal is for the package builder to create both 32b and 64b packages. When this is not possible, the 32b packager MUST find another package builder to compile the matching 64b package. It is also imperative if builds are split between 2 packagers - that same source and build method is used.
32b packages are always backported with dpkg-buildpackage -rfakeroot -sa for signed or dpkg-buildpackage -rfakeroot -us -uc -sa for unsigned. This creates all of the necessary packages for upload to the repo including source (packname_version.orig.tar.gz), .dsc and .changes files, and the appropriate deb files - including "all" deb files where used for both architectures- eg common data debs etc.
64b packages are always backported with dpkg-buildpackage -rfakeroot -B for signed or dpkg-buildpackage -rfakeroot -us -uc -B for unsigned. This creates only the architecture dependent (amd64) deb files + amd64.changes file for upload to the repo. The reason for not including source, .diff, .dsc (and "all" architecture files if applicable) is that these files would have already been created when compiling the 32b version. The repo cannot handle the same file twice.

[edit]

Uploading to Maintainer & Repo

Packagers should discuss with their Maintainer to ascertain which method of upload works best in their pod. One method is for all packages to be zipped and uploaded to free filesharing site (eg Rapidshare / Filefront) and link emailed to Maintainer. This has the advantage of not clogging email.
Maintainers MUST ensure that 32b packages (ie full set - source, dsc, diff, changes, debs) are uploaded to repo before 64b. It is OK to upload both 32b and 64b simultaneously - but definitely not 64b without the 32b.

Retrieved from "http://www.mepis.org/docs/en/index.php/Mepis_Package_Building_Guide"

Category: Packaging

Mepis Package Building Guide

From MEPIS Documentation Wiki

Contents

Setting The Environment

Environment (Essential)

Packaging For Mepis Official Repository

Packaging For Mepis Community Repository (main non-free)

Packaging For Mepis Community Repository (restricted)

Environment (Recommended)

Software (Essential)

Preconfiguration

Documentation

Recommended Reading

Recommended Reading – Web

Base Procedure – Packaging for Official Mepis & Community Repos

Packager (part 1)

Maintainer (part 1)

Testers

Packager (part 2)

Maintainer (Part 2)

Developer

Versioning

Recommended Package Creation Methods

Basic Package Creation Decision Tree

Details of Each Method

1 Backporting From Upstream Debian (Recommended Method)

2. Repackaging from Debian Backports

3. Backporting from Ubuntu Repository

4. Packaging from Bare Source Tarball

Special Notes - IMPORTANT

General

32b / 64b

Uploading to Maintainer & Repo

Personal tools

Navigation

Search