Appendice A. Pacchettizzazione avanzata
Indietro     

Appendice A. Pacchettizzazione avanzata

Indice

A.1. Librerie condivise
A.2. Gestire debian/package.symbols
A.3. Multiarch
A.4. Costruzione del pacchetto della libreria condivisa
A.5. Pacchetto nativo Debian

Here are some hints and pointers for advanced packaging topics that you are most likely to deal with. You are strongly advised to read all the references suggested here.

Può essere necessario modificare manualmente il file del template del pacchetto generato dal comando dh_make per affrontare gli argomenti trattati in questo capitolo. Il nuovo comando debmake potrebbe trattare questi temi in modo migliore.

A.1. Librerie condivise

Prima di pacchettizzare una libreria condivisa, si dovrebbero leggere attentamente i seguenti riferimenti principali:

Di seguito alcuni semplici suggerimenti per iniziare:

  • Le librerie condivise sono file oggetto ELF che contengono del codice compilato.

  • Le librerie condivise sono distribuite come file *.so. (Né come file *.a né come file *.la)

  • Le librerie condivise sono utilizzate principalmente per condividere codice tra più eseguibili, utilizzando il sistema ld.

  • Le librerie condivise sono a volte utilizzate per fornire plugin a più di un file eseguibile con il sistema dlopen.

  • Shared libraries export symbols, which represent compiled objects such as variables, functions, and classes; and enable access to them from the linked executables.

  • Il SONAME di una libreria condivisa libfoo.so.1: objdump -p libfoo.so.1 | grep SONAME [88]

  • Il SONAME di una libreria condivisa di solito corrisponde al nome del file della libreria (ma non sempre).

  • Il SONAME delle librerie condivise collegate a /usr/bin/foo: objdump -p /usr/bin/foo | grep NEEDED [89]

  • libfoo1: il pacchetto libreria per la libreria condivisa libfoo.so.1 con la versione SONAME ABI 1.[90]

  • Gli script dei maintainer riguardanti i pacchetti libreria devono richiamare ldconfig in circostanze specifiche per creare i necessari collegamenti simbolici per SONAME.[91]

  • libfoo1-dbg: the debugging symbols package that contains the debugging symbols for the shared library package libfoo1.

  • libfoo-dev: the development package that contains the header files etc. for the shared library libfoo.so.1.[92]

  • Debian packages should not contain *.la Libtool archive files in general.[93]

  • Debian packages should not use RPATH in general.[94]

  • Anche se un po' datato, ed è solo un riferimento secondario, Debian Library Packaging Guide può ancora essere utile.

A.2. Gestire debian/package.symbols

When you package a shared library, you should create a debian/package.symbols file to manage the minimal version associated with each symbol for backward-compatible ABI changes under the same SONAME of the library for the same shared library package name.[95] You should read the following primary references in detail:

Here is a rough example of how to create the libfoo1 package from the upstream version 1.3 with the proper debian/libfoo1.symbols file:

  • Preparare lo scheletro dell'albero del sorgente debianizzato utilizzando il file originale libfoo-1.3.tar.gz.

    • Se è il primo pacchetto per libfoo1, bisogna creare il file vuoto debian/libfoo1.symbols.

    • Se la versione originale (upstream) precedente 1.2 è stata pacchettizzata come libfoo1 con il file debian/libfoo1.symbols nei propri sorgenti del pacchetto, lo si utilizzi.

    • If the previous upstream version 1.2 was not packaged with debian/libfoo1.symbols, create it as the symbols file from all available binary packages of the same shared library package name containing the same SONAME of the library, for example, versions 1.1-1 and 1.2-1. [97] 

      $ dpkg-deb -x libfoo1_1.1-1.deb libfoo1_1.1-1
$ dpkg-deb -x libfoo1_1.2-1.deb libfoo1_1.2-1
$ : > symbols
$ dpkg-gensymbols -v1.1 -plibfoo1 -Plibfoo1_1.1-1 -Osymbols
$ dpkg-gensymbols -v1.2 -plibfoo1 -Plibfoo1_1.2-1 -Osymbols

  • Make trial builds of the source tree with tools such as debuild and pdebuild. (If this fails due to missing symbols etc., there were some backward-incompatible ABI changes that require you to bump the shared library package name to something like libfoo1a and you should start over again.) 

    $ cd libfoo-1.3
$ debuild
...
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ...
 see diff output below
--- debian/libfoo1.symbols (libfoo1_1.3-1_amd64)
+++ dpkg-gensymbolsFE5gzx        2012-11-11 02:24:53.609667389 +0900
@@ -127,6 +127,7 @@
  foo_get_name@Base 1.1
  foo_get_longname@Base 1.2
  foo_get_type@Base 1.1
+ foo_get_longtype@Base 1.3-1
  foo_get_symbol@Base 1.1
  foo_get_rank@Base 1.1
  foo_new@Base 1.1
...

  • If you see the diff printed by the dpkg-gensymbols as above, extract the proper updated symbols file from the generated binary package of the shared library. [98] 

    $ cd ..
$ dpkg-deb -R  libfoo1_1.3_amd64.deb libfoo1-tmp
$ sed -e 's/1\.3-1/1\.3/' libfoo1-tmp/DEBIAN/symbols \
        >libfoo-1.3/debian/libfoo1.symbols

  • Costruire la release dei pacchetti con programmi come debuild e pdebuild. 

    $ cd libfoo-1.3
$ debuild clean
$ debuild
...

In aggiunta agli esempi sopra riportati, è necessario controllare ulteriormente la compatibilità ABI e cambiare le versioni di qualche simbolo manualmente come richiesto. [99]

Anche se è solo un riferimento secondario,, Debian wiki UsingSymbolsFiles e i suoi collegamenti possono essere utili.

A.3. Multiarch

La funzionalità multiarch introdotta in Debian wheezy integra il supporto per l'installazione dei pacchetti binari cross-architettura (in particolare i386<->amd64, ma anche altre combinazioni) in dpkg e apt. Si consiglia di leggere attentamente i seguenti riferimenti:

Esso utilizza la tripletta come i386-linux-gnu e x86_64-linux-gnu per il percorso d'installazione delle librerie condivise. La tripletta del percorso reale è impostata con il valore dinamico $(DEB_HOST_MULTIARCH) da dpkg-architecture(1) per ogni costruzione. Ad esempio, il percorso per installare le librerie multiarch viene modificato come segue.[100]

Vecchio percorso percorso i386 multiarch percorso amd64 multiarch
/lib/ /lib/i386-linux-gnu/ /lib/x86_64-linux-gnu/
/usr/lib/ /usr/lib/i386-linux-gnu/ /usr/lib/x86_64-linux-gnu/

Here are some typical multiarch package split scenario examples for the following:

  • sorgente di libreria libfoo-1.tar.gz

  • sorgente di programma bar-1.tar.gz scritto con un linguaggio compilato

  • sorgente di programma baz-1.tar.gz scritto con un linguaggio interpretato

Pacchetto Architettura: Multi-Arch: Contenuto del pacchetto
libfoo1 qualsiasi uguale la libreria condivisa, co-installabile
libfoo1-dbg qualsiasi uguale i simboli di debug della libreira condivisa, co-installabile
libfoo-dev qualsiasi uguale i file di header, ecc, della libreira condivisa, co-installabile
libfoo-tools qualsiasi straniero il programma di supporto run-time, non co-installabile
libfoo-doc tutti straniero i file di documentazione della libreria condivisa
bar qualsiasi straniero i file del programma compilato, non co-installabile
bar-doc tutti straniero i file di documentazione del programma
baz tutti straniero i file del programma interpretato

Si prega di notare che il pacchetto di sviluppo dovrebbe contenere un link simbolico per la libreria condivisa associata senza un numero di versione. Ad es.: /usr/lib/x86_64-linux-gnu/libfoo.so -> libfoo.so.1

A.4. Costruzione del pacchetto della libreria condivisa

You can build a Debian library package enabling multiarch support using dh(1) as follows:

Ci si assicuri di verificare che il pacchetto di libreria condivisa contenga solo i file attesi, e che il pacchetto -dev continui a funzionare.

All files installed simultaneously as the multiarch package to the same file path should have exactly the same file content. You must be careful of differences generated by the data byte order and by the compression algorithm.

A.5. Pacchetto nativo Debian

Se il pacchetto è mantenuto solo per Debian o per uso locale, il suo sorgente potrebbe contenere tutti i file in debian/*. In questo caso, ci sono 2 modi per pacchettizzarlo.

You can make the upstream tarball by excluding the debian/* files and package it as a non-native Debian package as in Sezione 2.1, «Flusso di lavoro per la costruzione dei pacchetti Debian». This is the normal way, which some people encourage using.

L'alternativa è utilizzare lo stesso metodo usato dai pacchetti Debian nativi.

  • Creare un pacchetto sorgente nativo di Debian nel formato 3.0 (native) usando un singolo file tar compresso che include tutti i file.

    • pacchetto_versione.tar.gz
    • pacchetto_versione.dsc

  • Costruire pacchetti binari Debian dal pacchetto sorgente nativo di Debian.

    • pacchetto_versione_arch.deb

For example, if you have source files in ~/mypackage-1.0 without the debian/* files, you can create a native Debian package by issuing the dh_make command as follows: 

$ cd ~/mypackage-1.0
$ dh_make --native

Then the debian directory and its contents are created just like in Sezione 2.8, «Il primo pacchetto non nativo per Debian». This does not create a tarball, since this is a native Debian package. But that is the only difference. The rest of the packaging activities are practically the same.

Dopo l'esecuzione del comando dpkg-buildpackage, si possono vedere i seguenti file nella directory principale:

  • mypackage_1.0.tar.gz

    Questo è l'archivio del codice sorgente creato dalla directory mypackage-1.0 dal comando dpkg-source. (Il suffisso non è orig.tar.gz.)

  • mypackage_1.0.dsc

    This is a summary of the contents of the source code, as in the non-native Debian package. (There is no Debian revision.)

  • mypackage_1.0_i386.deb

    This is your completed binary package, as in the non-native Debian package. (There is no Debian revision.)

  • mypackage_1.0_i386.changes

    Questo file descrive tutte le modifiche apportate nella versione attuale del pacchetto, come per i pacchetti Debian non-nativi. (non c'è revisione Debian.)


[88] In alternativa: readelf -d libfoo.so.1 | grep SONAME

[89] In alternativa: readelf -d libfoo.so.1 | grep NEEDED

[95] Le modifiche ABI incompatibili con le versioni precedenti, normalmente rendono necessario aggiornare il SONAME della libreria e il nome del pacchetto della libreria condivisa a quelli nuovi.

[96] Per le librerie C++ e per gli altri casi in cui il tracciamento dei singoli simboli è troppo difficile, si consulti invece Manuale delle policy di Debian, 8.6.4 "The shlibs system", instead.

[97] Tutte la versioni precedenti del pacchetto Debian packages sono disponibili su http://snapshot.debian.org/. La revisione Debian viene eliminata dalla versione per rendere più facile il backport del pacchetto: 1.1 << 1.1-1~bpo70+1 << 1.1-1 and 1.2 << 1.2-1~bpo70+1 << 1.2-1

[98] La revisione Debian viene eliminata dalla versione per rendere più facile il backport del pacchetto: 1.3 << 1.3-1~bpo70+1 << 1.3-1

[100] Old special purpose library paths such as /lib32/ and /lib64/ are not used anymore.

[101] In alternativa, si possono aggiungere gli argomenti --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) e --libexecdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) a ./configure. Si noti che --libexecdir indica il percorso predefinito d'installazione dei programmi eseguibili gestiti da altri programmi e non dagli utenti. Il percorso predefinito di Autotools è /usr/libexec/ mentre quello di Debian è /usr/lib/.

Indietro     
Capitolo 9. Caricamento del pacchetto  Partenza