joliclic blog

2.4.1 Prerequisites

In this part we will create a rpm package, for rpm based distributions, like Red Hat, Fedora, Suse,... (I have tested only with Fedora, please let me know if there's any problems for others).

We can create this rpm from other Linux distributions as well, Debian based for example (that's what I do), we just need the rpmbuild executable, we have just to install rpm:

apt-get install rpm

Some documentation links:

• The RPM Guide from Fedora
• The Packaging:Guidelines in the Fedora wiki.
• and the Maximum RPM guide from rpm.org
• This pdf documentation from www.gurulabs.com is useful to understand the creation of rpm.

I suppose we don't have any needed compilation, but if you have some, simply do it before packaging (despite the fact this is not recommended in this guide).

2.4.2 RPM files

To build a rpm, we're supposed to setup a user configuration for all rpm creation. But it is possible to do it in a local folder, that's what we will do.

We need to create the following folders, and a myapp.spec file:

    |- samples_chapter_2/
        |- myapp/
        |- rpmbuild/
            |- BUILD/
            |- RPMS/
            |- SOURCES/
            |- SPECS/
            |- SRPMS/
            |- myapp.spec

In fact this is the same structure than the required rpm environnement, but locally.

The .spec file is the 'script' used by rpmbuild to create the rpm. It is supposed to use a source tar.gz archive, that we will build especially later.

Here's the content of our spec:

Name:           myapp
Version:        1.0
Release:        1%{?dist}
Summary:        simple Hello World powered by XULRunner.

Group:          Development/Tools
License:        MPLv1.1 or GPLv2+ or LGPLv2+
URL:            http://example.com/myapp/
Source:         myapp-1.0.tar.gz
BuildArch:      noarch
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id} -un)

#BuildRequires:  
Requires:       firefox >= 3.6

%description
simple Hello World
Powered by XULRunner.

%prep
%setup

%build

%install
rm -rf %{buildroot}
mkdir -p %{buildroot}%{_libdir}
cp -R myapp %{buildroot}%{_libdir}/
mkdir -p %{buildroot}%{_bindir}

ln -s %{_libdir}/myapp/myapp.sh %{buildroot}%{_bindir}/myapp

mkdir -p %{buildroot}%{_datadir}/applications
cp data/myapp.desktop %{buildroot}%{_datadir}/applications/

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/16x16/apps
cp data/icons/icon16.png \
    %{buildroot}%{_datadir}/icons/hicolor/16x16/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/22x22/apps
cp data/icons/icon22.png \
    %{buildroot}%{_datadir}/icons/hicolor/22x22/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/32x32/apps
cp data/icons/icon32.png \
    %{buildroot}%{_datadir}/icons/hicolor/32x32/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/48x48/apps
cp data/icons/icon48.png \
    %{buildroot}%{_datadir}/icons/hicolor/48x48/apps/myapp.png

mkdir -p %{buildroot}%{_datadir}/icons/hicolor/scalable/apps
cp data/icons/icon48.svg \
    %{buildroot}%{_datadir}/icons/hicolor/scalable/apps/myapp.svg

%post
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
  %{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi

%postun
touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :
if [ -x %{_bindir}/gtk-update-icon-cache ]; then
  %{_bindir}/gtk-update-icon-cache -q %{_datadir}/icons/hicolor;
fi


%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)
%{_bindir}/myapp
%{_libdir}/myapp
%{_datadir}/applications/myapp.desktop
%{_datadir}/icons/hicolor/16x16/apps/myapp.png
%{_datadir}/icons/hicolor/22x22/apps/myapp.png
%{_datadir}/icons/hicolor/32x32/apps/myapp.png
%{_datadir}/icons/hicolor/48x48/apps/myapp.png
%{_datadir}/icons/hicolor/scalable/apps/myapp.svg
#%doc

%changelog
* Fri Oct  8 2010 John Doe <johndoe@example.com> 1.0-1
- first publication

Let see in detail some entries of this file:

The Name should not contain any whitespace characters.

The Version must contain only number and digit, no string like "beta".

The Group entry must be chosen in the list in the /usr/share/doc/rpm/GROUPS file. You should have it on your computer since you have installed rpm.

The Release is the version of the rpm for this version of the app, and %{?dist} will be replaced by rpmbuild by the current distribution. It will not be completed on a non rpm distribution, you can remove it if you want.

For the License entry, you must choose a short keyword from this list.

The Source entry must match exactly the tar.gz that we will create later.

The BuildArch: noarch line specify that our app is not architecture specific. If your app contains some compiled code, you must remove this line, and a rpm specific to the current architecture will be build.

The BuildRoot value is a usual one.

The BuildRequires is commented (with a #), as we have no compilations.

Finally, the Requires entry contains the other packages that are needed by our app. You could add others, separated by comma (,). Note that you can't declare alternative dependencies like with deb. That's why we declare Firefox and not XULRunner as dependencies, in the eventual case where the Firefox of the distribution is not XULRunner based.

Later we will copy the tar.gz archive of our app into the SOURCES folder.
Then the %prep section and the %setup instruction will unpack it into the BUILD folder.
The %build section is empty, because we have no compilation to do.

In the %install section, we install our app.
These are some shell commands, the current working directory is the unpacked source tar.gz. %{buildroot} is the root of the local installation of our app, this will be the computer root / in the real installation.
%{_libdir}, %{_bindir}, and %{_datadir} corresponds respectively to /usr/lib/, /usr/bin/, and /usr/share/. I guess that's the case for main rpm based distros, If I'm wrong, please correct me, it means that some these variables should be redefined.
So in this section, we re-create the initial buildroot folder. Then we create the link to our launcher in /usr/bin/, copy our app in /usr/lib/, and copy the desktop file and our icons into the right location in /usr/share/.

The %post and %postun sections declare some actions after that our app will be installed and uninstalled. We update the icons database for the windows manager.
If the app handle some mime types, i.e. can open some type of files, this should be specified in the .desktop file. And you must add the following code in these %post and %postun sections:

if [ -x /usr/bin/update-desktop-database ]; then
    update-desktop-database &> /dev/null || :
fi

The %files section is required, and contains the complete list of files/folders installed by our app.

Finally, the format of the %changelog section, is described in this doc.

2.4.3 Create the rpm

So now that we have all that we need, we will create a script to create a fake source archive for rpmbuild, which contains our app, our desktop file, and our icons. We will place this archive in the SOURCES folder, then invoke rpmbuild locally with our spec file. And in fact, we will doing all of this in a temporary folder, to let our sources clean.

Note: rmpbuild seems to bug if there's some whitespace in the path of the working folder, so be careful with the name of the (sub)directories where you place your sources.
The following script will abort if this is the case.

Here this script:

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp
SRC_VERSION=1.0

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

# copy the rmpbuild tree folder
cp -rv rpmbuild/* "$TMP_DIR/"

# create a source tar.gz archive for rpmbuild into SOURCES
mkdir -v "$TMP_DIR/myapp-$SRC_VERSION"
cp -rv myapp "$TMP_DIR/myapp-$SRC_VERSION/"
cp -rv data "$TMP_DIR/myapp-$SRC_VERSION/"
cd "$TMP_DIR"
# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;
tar -zcvf  "$TMP_DIR/SOURCES/myapp-$SRC_VERSION.tar.gz" \
    "myapp-$SRC_VERSION"
cd -
rm -rv "$TMP_DIR/myapp-$SRC_VERSION"

# rmpbuild seems to have a bug, it can't handle a _topdir with whitespace
if [ -n "$(echo "$TMP_DIR" | grep '[ ]')" ]; then
    echo "the path '$TMP_DIR' contains whitespace, rpmbuild will failed. script aborted!"
    exit 1
fi

# build the rpm from our spec, specify our local build tree
rpmbuild --define="_topdir $TMP_DIR" -bb "$TMP_DIR/myapp.spec"

# and finally copy our created rpm in to into the current folder
cp -v "$TMP_DIR/RPMS/noarch/myapp-$SRC_VERSION-1.noarch.rpm" ./

To create our rpm, in a terminal:

• cd samples_chapter_2

• sh ./build_rpm.sh

And as result we have finally the file myapp-1.0-1.noarch.rpm in the myapp-src folder :) .

2.2.1 Synopsis

Ok, nous avons notre lanceur, et tous les fichiers nécessaires à l'intégration au bureau (voir le chapitre 2.1). Nous allons maintenant créer un paquet deb, pour les distributions basées sur Debian, comme Ubuntu.

La principale documentation pour la création de deb est Debian Policy Manual. et vous pouvez trouver également utile cette autre doc de Debian et celle ci d'Ubuntu.

Je suppose que notre appli ne contient pas de code compilé, mais si c'est le cas, compilez le simplement avant de créer le paquet. Nous créerons ce deb manuellement.

Nous allons utiliser debhelper et fakeroot. Nous devons créer quelques fichiers utilisés par les scripts debian, copier nos sources et fichiers de bureau aux bons emplacements, et exécuter quelques scripts.

Pour celà, nous devons installer debhelper et fakeroot.

sur Debian/Ubuntu:

• apt-get install debhelper fakeroot

Sur Fedora, malheureusement debhelper n'est pas encore disponible dans les dépôts, mais devrait l'être un jour, voir les bugs #591190, #591389, #642160, et #591332.

Sur OpenSuse il y a un paquet nommé 'deb' qui l'installe.

sur les autres distributions... faites le moi savoir ;)

Le deb créé installera myapp dans le dossier /usr/lib/ , c'est l'emplacement standard sur Linux.

2.2.2 Fichiers Debian

pour construire notre deb, nous devons créer un dossier debian à coté de notre application, contenant plusieurs fichiers utilisés par les programmes de debhelper
Vous pouvez utiliser dh_make pour créer un tel squelette, mais ici nous allons créer ces fichiers nous-même :

    |- samples_chapter_2/
        |- myapp/
        |- debian/
            |- changelog
            |- compat
            |- control
            |- copyright
            |- menu
            |- postinst
            |- myapp.links

Le fichier changelog est décrit en détail ici dans la doc, il contient :

myapp (1.0-1) unstable; urgency=low

  * Initial release

 -- John Doe <johndoe@example.com>  Fri, 26 Nov 2010 10:10:35 +0100

Note : soyez précis dans le format de ce fichier, il doit réellement être précis, voir la doc.

Note : la date doit être au format RFC822, vous pouvez l'obtenir avec date -R dans un terminal.

Le fichier compat contient simplement la compatibilité de debhelper, soit juste 7 .

Le fichier control est le plus important. Voici un exemple :

Source: myapp
Section: Utilities
Priority: extra
Maintainer: John Doe <johndoe@example.com>
Build-Depends: debhelper (>= 7)
Standards-Version: 3.7.2
Homepage: <http://example.com/myapp/>

Package: myapp
Architecture: all
Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6)
Description: simple Hello World.
  Powered by XULRunner.

Choisissez une Section dans cette liste.

Si votre application contient du code compilé, vous devez supprimer la ligne Architecture: all, car son but est précisement de créer un paquet indépendant de la plateforme. Sans cette entrée, le deb sera spécifique à l'architecture actuelle.

Si votre appli nécessite d'autres dépendances, ajoutez les séparés par une virgule. Si l'appli contient du code compilé, vous pouvez vouloir utiliser la valeur ${shlibs:Depends}, ainsi à la construction du paquet certaines dépendances seront calculées. Par exemple :

Depends: xulrunner (>= 1.9.2) | firefox (>= 3.6), ${shlibs:Depends}

Le format du champ Description est décrit en détail dans cette doc.

Le fichier copyright peut contenir par exemple :

This package was debianized by John Doe <johndoe@example.com> on
Sat, 16 Oct 2010 17:55:17 +0200

It was downloaded from <http://example.com/myapp/>

Upstream Author(s):
    John Doe <johndoe@example.com>

Copyright:
    <Copyright (C) 2010 John Doe>

License:
    ***** BEGIN LICENSE BLOCK *****
    Version: MPL 1.1/GPL 2.0/LGPL 2.1
    
    The contents of this file are subject to the Mozilla Public License Version 
    1.1 (the "License"); you may not use this file except in compliance with 
    the License. You may obtain a copy of the License at 
    http://www.mozilla.org/MPL/
    
    Software distributed under the License is distributed on an "AS IS" basis,
    WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
    for the specific language governing rights and limitations under the
    License.
    
    The Original Code is MyApp.
    
    The Initial Developer of the Original Code is John Doe.
    Portions created by the Initial Developer are Copyright (C) 2010
    the Initial Developer. All Rights Reserved.
    
    Contributor(s):
    John Doe (johndoe@example.com)
    
    Alternatively, the contents of this file may be used under the terms of
    either the GNU General Public License Version 2 or later (the "GPL"), or
    the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
    in which case the provisions of the GPL or the LGPL are applicable instead
    of those above. If you wish to allow use of your version of this file only
    under the terms of either the GPL or the LGPL, and not to allow others to
    use your version of this file under the terms of the MPL, indicate your
    decision by deleting the provisions above and replace them with the notice
    and other provisions required by the GPL or the LGPL. If you do not delete
    the provisions above, a recipient may use your version of this file under
    the terms of any one of the MPL, the GPL or the LGPL.
    
    ***** END LICENSE BLOCK *****

Le fichier menu contient :

?package(myapp):needs="X11" section="Applications/Programming"\
  title="MyApp" command="/usr/bin/myapp"

Choisissez une section dans cette liste.

Le fichier postinst est un script lancé à la fin de l'installation du deb. Il permet de reconstruire le cache des icônes système par exemple.

#!/bin/sh
# postinst script for myapp
#
# see: dh_installdeb(1)

set -e

# summary of how this script can be called:
#        * <postinst> `configure' <most-recently-configured-version>
#        * <old-postinst> `abort-upgrade' <new version>
#        * <conflictor's-postinst> `abort-remove' `in-favour' <package>
#          <new-version>
#        * <postinst> `abort-remove'
#        * <deconfigured's-postinst> `abort-deconfigure' `in-favour'
#          <failed-install-package> <version> `removing'
#          <conflicting-package> <version>
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package

case "$1" in
    configure)
        # for icons of the app
        if [ -x /usr/bin/gtk-update-icon-cache ]; then
            gtk-update-icon-cache -f /usr/share/icons/hicolor
        fi
        
        # uncomment only if the installed app handle some mime-type
        #if [ "$2" == "" ]; then
        #    if [ -x /usr/bin/update-desktop-database ]; then
        #        update-desktop-database /usr/share/applications
        #    fi
        #fi
    ;;

    abort-upgrade|abort-remove|abort-deconfigure)
    ;;

    *)
        echo "postinst called with unknown argument \`$1'" >&2
        exit 1
    ;;
esac

# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.

#DEBHELPER#

exit 0

Enfin, le fichier myapp.links contient les liens à créer après l'installation du deb.

/usr/lib/myapp/myapp.sh /usr/bin/myapp

2.2.3 Créer le deb

Ok, nous avons maintenant tous les fichiers nécessaires, nous pouvons créer notre deb. Nous devons créer un dossier portant le même nom que notre application dans le dossier debian, et y copier les fichiers de la même manière que sur le système final.

    |- debian/
        |- myapp/
            |- usr
                |- lib
                    |- myapp/
                |- share
                    |- applications/
                        |- myapp.desktop
                    |- icons/
                        |- hicolor/
                            |- 16x16/
                                |- apps
                                    |- myapp.png
                            |- 22x22/
                                |- apps
                                    |- myapp.png
                            |- 32x32/
                                |- apps
                                    |- myapp.png
                            |- 48x48/
                                |- apps
                                    |- myapp.png
                            |- scalable/
                                |- apps
                                    |- myapp.svg

Et nous allons appliquer quelques script debhelper.

Voici un script shell complet, nommé build_deb.sh, il crée un dossier temporaire 'tmp', et y copie nos fichiers debian, notre application, et nos fichiers desktop, puis crée le deb :

#!/bin/bash

# exit the script on errors
set -e

TMP_DIR=./tmp

# get the absolute path of our TMP_DIR folder
TMP_DIR=$(readlink -f -- "$TMP_DIR")

# re-create the TMP_DIR folder
rm -rfv "$TMP_DIR"
mkdir -v "$TMP_DIR"

#copy the debian folder into TMP_DIR
cp -rv "./debian" "$TMP_DIR/"

# create into TMP_DIR the folder where copy our app
mkdir -pv "$TMP_DIR/debian/myapp/usr/lib"

# and copy the app
cp -rv "./myapp" "$TMP_DIR/debian/myapp/usr/lib/"

# create the folder for the .desktop file and copy it
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/applications"
cp -v "./data/myapp.desktop" \
    "$TMP_DIR/debian/myapp/usr/share/applications/"

# create the folder and copy our icons
mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps"
cp -v "./data/icons/icon16.png" \
    "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/16x16/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps"
cp -v "./data/icons/icon22.png" \
    "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/22x22/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps"
cp -v "./data/icons/icon32.png" \
    "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/32x32/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps"
cp -v "./data/icons/icon48.png" \
    "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/48x48/apps/myapp.png"

mkdir -pv "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps"
cp -v "./data/icons/icon48.svg" \
    "$TMP_DIR/debian/myapp/usr/share/icons/hicolor/scalable/apps/myapp.svg"

cd "$TMP_DIR"

# clean eventual tempory files
find . -type f -name *.*~ -exec rm {} \;

# deb creation
fakeroot dh_link
fakeroot dh_fixperms
fakeroot dh_installdeb
# uncomment the following line if you have some compiled code and use ${shlibs:Depends} in control file
#dh_shlibdeps
fakeroot dh_gencontrol
fakeroot dh_md5sums
fakeroot dh_builddeb

echo "deb created for myapp :)"

Pour créer notre deb, dans un terminal :

• cd samples_chapter_2

• sh ./build_deb.sh

En résultat nous avons finalement le fichier myapp_1.0-1_all.deb dans le dossier samples_chapter_2 :) .

2.1.1 Généralités

Nous ciblons la plateforme Linux dans cette partie. Et c'est le cas le plus simple.

Pour toutes les distributions que j'ai essayées, XULRunner est disponible depuis le gestionnaire de paquets, et Firefox est basé sur lui. Donc XULRunner peut facilement être une dépendance de notre application.

2.1.2 Créer un lanceur

Il est facile de créer un lanceur, créons simplement un script shell nommé myapp.sh, dans le dossier principal de notre application (celui qui contient application.ini), avec le contenu suivant :

#!/bin/sh

CUR_DIR=$(dirname $(readlink -f "$0"))

if [ -x /usr/bin/xulrunner ]; then
    /usr/bin/xulrunner "$CUR_DIR/application.ini" $@
elif [ -x /usr/bin/firefox ]; then
    /usr/bin/firefox -app "$CUR_DIR/application.ini" $@
else
    echo "Error: unable to find XULRunner or Firefox!"
fi

et rendons le exécutable :

chmod +x myapp.sh

Le script trouve dans quel dossier il se trouve, puis lance le fichier application.ini via xulrunner s'il le trouve, sinon via firefox avec l'argument -app. Le script passe aussi les éventuels arguments supplémentaires (comme -jsconsole par exemple).

Plus tard dans ce tutoriel, quand nous créerons les paquets deb et rpm, nous ajouterons un lien symbolique vers ce fichier dans /usr/bin .

Note: l'argument -f de readlink utilisé dans ce script est disponible uniquement dans la version GNU, donc dans toutes les distributions Linux, mais pas forcément sur d'autres systèmes de type Unix, comme Mac OSX par exemple.

2.1.3 Des icônes pour nos fenêtres

Pour l'instant, notre application est lancée, mais l'icône affichée dans la barre de tâches est celle générique de XULRunner, ou celle de Firefox. Il est facile d'afficher notre propre icône. Créons simplement un dossier nommé 'icons' à l'intérieur du dossier chrome principal de notre appli, puis créons dans celui-ci un autre nommé 'default'. Copions 3 fichiers png, nommés default16.png, default32.png, et default48.png. Et c'est tout, maintenant c'est notre icône qui est affichée.

    |- samples_chapter_2/
        |- myapp/
            |- chrome
                |- icons/
                    |- default/
                        |- default16.png
                        |- default32.png
                        |- default48.png

 2.1.4 Intégration au bureau

Pour une intégration complète au bureau, nous devons maintenant créer quelques fichiers supplémentaires, un fichier .desktop, et quelques icône associées. Ainsi notre appli apparaitra dans le menu Applications du gestionnaire de fenêtres.

En exemple, voici le contenu d'un fichier myapp.desktop :

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=MyApp
Comment=a Hello World XULRunner app
Comment[fr]=un Bonjour Monde pour XULRunner.
Exec=/usr/bin/myapp
Terminal=false
Type=Application
Categories=Utility;
Icon=myapp

Voir cette documentation pour les détails, et celle ci pour choisir les Catégories.

L'entrée Exec est décrite en détail ici, nous utilisons un lien symbolique vers notre lanceur, depuis /usr/bin/ (le standard pour les exécutables sur Linux). Son emplacement réel sera dans /usr/lib/myapp/.

L'entrée Icon contient le nom de notre icône, que nous créerons par la suite.

L'entrée Comment est optionnelle, et peut être localisée (comme quelques autres entrées, voyez la spécification), ici nous définissons sune valeur par défaut, et une française (fr).

Si l'appli gère certains types mime, i.e. peut ouvrir certains types de fichiers, vous devez ajouter une ligne avec l'entrée MimeType, par exemple :

MimeType=text/html;text/xml;application/xhtml+xml;

Ce fichier myapp.desktop est sensé être placé à l'étape finale dans le dossier /usr/share/applications/ folder.
(Voir http://www.freedesktop.org/wiki/Specifications/menu-spec et http://www.freedesktop.org/wiki/Specifications/basedir-spec pour plus de détail)

Maintenant nous avons besoin de quelques icônes. Nous utiliserons des png et svg (xpm est également possible, mais semble déprécié, nous n'utiliserons pas ce format). Nous pouvons avoir différentes tailles, personnellement je me restreint à 4 png (16x16, 22x22, 32x32, 48x48), comme suggéré par les Tango Guidelines, plus un svg de 48x48.

Ces images doivent être nommées myapp.png, et myapp.svg .

Et elles doivent finalement être placées dans les dossiers suivants :

• /usr/share/icons/hicolor/16x16/apps/myapp.png
• /usr/share/icons/hicolor/22x22/apps/myapp.png
• /usr/share/icons/hicolor/32x32/apps/myapp.png
• /usr/share/icons/hicolor/48x48/apps/myapp.png
• /usr/share/icons/hicolor/scalable/apps/myapp.svg

 2.1.5 Distribuer un tar.gz

Notre application est utilisable telle quelle avec son lanceur, vous pouvez donc la distribuer avec un simple tar.gz. Pour le créer :

tar -zcvf myapp.tar.gz myapp

Un utilisateur peut le télécharger, le décompresser n'importe où, et lancer l'appli via myapp.sh.

Mais pour être plus convivial, un paquet utilisable avec le gestionnaire de paquet de sa distribution, avec l'intégration au bureau complète, est préférable. C'est ce que nous verrons dans les prochaines sections.