Mepis Package Building Guide

From MEPIS Documentation Wiki

(Redirected from Mepis Packaging Guide WIP)
Jump to: navigation, search

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

Contents

[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

  • 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 can be installed and enabled – this is in fact encouraged.
  • Debian backports repository disabled – they are not always compatible with Mepis


[edit]

Environment (Recommended)

  • Clean separate install of MEPIS (current version is 7) 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


[edit]

Preconfiguration

  • Add in ~/.bashrc (a hidden text file in your home directory) these environment variables:
export DEBEMAIL=your@email.address (use your email address!)
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

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!

[edit]

Documentation

[edit]

Recommended Reading

Debian Packaging Documentation – optional – but should be read along with this document. Gives insights into debian packaging procedures.

apt-get install debian-policy developers-reference
  • Debian-policy: the Policy includes explanations of the structure and contents of the Debian archive, several OS design issues, the Filesystem Hierarchy Standard (which says where each file and directory should be) etc. For you, the most important thing is that it describes requirements that each package must satisfy to be included in the distribution. (see /usr/share/doc/debian-policy/policy.html/index.html)
  • Developers-reference: for all matters not specifically about the technical details of packaging, like the structure of the archive, how to rename, orphan, pick up packages, how to do NMUs (Non-Maintainers Uploads), how to manage bugs, best packaging practices, when and where to upload etc. (see /usr/share/doc/developers-reference/index.en-us.iso-8859-1.html)
[edit]

Recommended Reading – Web

[edit]

Base Procedure – Packaging for Official Mepis & Community Repos

[edit]

Packager

  1. Packager uses one of recommended methods (in this procedure) for creating debian package
  2. Following successful deb creation, Packager tests installing the created deb, and if successful, sends completed package to the Mepis Maintainer (s).
[edit]

Maintainer (part 1)

  1. On receipt of package from packager, Maintainer first scans deb file with A-V scanner
  2. Maintainer then checks built package for correctly maintained files and corrects if necessary.
  3. Maintainer sends checked debs to Testers for thorough testing.
[edit]

Testers

  1. Testers install debs and commence thorough checking of application.
  2. Any errors / lack of functionality are noted
  3. Following full testing, feedback is sent to Maintainer.
[edit]

Maintainer (part 2)

  1. Maintainer acts on Tester feedback.
  2. If package fails successful testing with errors or loss of functionality, errors are relayed to packager for correction.
  3. If package passes testing with full functionality, Maintainer checks version is correct and rescans (A-V) completed files.
  4. Package is either sent to Developer certified as correct and ready for Mepis repositories , OR
  5. If only intended for Community repositories, package and source is uploaded to Community server & community notified of new package availability.
[edit]

Developer

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

Versioning

  1. 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)
  2. If the version ends in debian1 or ubuntu1 etc, drop the debian or ubuntu minor version number.
  3. Be very careful not to increase the version number any more than you have to
  4. 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.

  1. 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".
  2. 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.
  3. 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, 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".
  4. 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.
  5. 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.
  6. Type "cd " and hit tab. The newly created folder's name should be automatically filled in. Hit enter to change to the source folder.
  7. 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
  8. Change "unstable" or "testing" to "stable". For the community repo, this should be changed to "etch" for Mepis 7.0 and "lenny" for Mepis 8.0. 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.
  9. Type "cd debian" into the console and hit enter to change to the Debian directory.
  10. Type "kwrite control" and hit enter to open the /debian/control file in Kwrite. You can use your preferred text editor instead of Kwrite.
  11. 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.
  12. Type "cd .." into the console and hit enter to return to the source directory.
  13. 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. 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.
    • 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.
  14. 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.
  15. 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!
  16. 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

  1. Download source file.
  2. Untar (extract) the source package to your normal test directory.
  3. Go to the unzipped directory and throughly 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.
  4. 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
  5. 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.
  6. If package does not configure or make, note errors and correct problems until you can cleanly install and test.
  7. 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.
  8. 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 -s -n
  9. 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.
  10. 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.
  11. 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).
  12. 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.
  13. 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.
  14. Test the completed package and upload to maintainer.
  1. 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.

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