Changes between Version 10 and Version 11 of TalkPackaging


Ignore:
Timestamp:
03/13/10 17:41:09 (10 years ago)
Author:
stefanor
Comment:

things I should have said :)

Legend:

Unmodified
Added
Removed
Modified
  • TalkPackaging

    v10 v11  
    126126=== The world of Debian === 
    127127 
     128 * Install `devscripts`, `python-support` and `build-essential`. 
     129   * To download the sample package, you can run: 
     130{{{ 
     131dget -xu http://ctpug.org.za/raw-attachment/wiki/TalkPackaging/hellopy_1.9-1.dsc 
     132}}} 
    128133 * Package your source up nicely using `sdist` 
    129134 * Things get named `name_version.orig.tar.gz` 
     135   * You can use `uscan` to download, repack, and rename it for you if you create a `debian/watch` file appropriately. You should do this. 
    130136 * Unpack the source distribution, and run `dh_make` 
     137   * Go for `single binary` mode. It's the simplest. 
    131138 * Look through the different example files that are produced: 
    132139   * There are loads of them, you don't have to use all of them 
    133140   * `debian/control` tells what different packages should be produced 
    134      * You can have separate `binary` and `source` files 
    135    * `debian/copyright` is important to signal the licenses etc, following Debian rules 
     141     * The first block is for the `source` package (the one you are working on). Later blocks for the `binary` packages you will get it to build. 
     142     * Call the binary package `python-$libname` to follow convention 
     143     * `Architecture`: `any` means build on every architecture; `all` means just build one package for all architectures (pure python). 
     144     * `Description` - first line is summary, the rest is detail 
     145     * Format is the same as email: To continue on a new line, put a space as the first character; for a blank line use `<space><dot>` like so: ` .` 
     146     * `XS-Python-Version`: You can set this to `all` or `>= 2.5`, etc. (`/usr/share/doc/python-support/README.gz`) 
     147     * Specify `Build-Depends: debhelper (>= 7), python-support`. Include anything here for building documentation and running tests. Depend on `python-all` if you want to test on all supported Python versions. 
     148     * `Depends`: calls the macro `${python_Depends}` 
     149   * `debian/copyright` is important to signal the licenses etc, following Debian rules. 
     150     * You can use [http://dep.debian.net/deps/dep5/ DEP5 format] or prose. 
    136151   * `debian/rules` is a makefile that generates a deb 
    137      * It's a lot of work to write all the rules, so there are a lot of helper tools 
     152     * It's a lot of work to write all the rules, so there are a lot of helper tools: debhelper, cdbs, dh (debhelper 7) 
    138153     * This used to involve lots of separate build steps 
    139154     * debhelper 7 is the way to go nowadays... Now you just use `dh`: 
    140155{{{ 
    141  
    142156#!/usr/bin/make -f 
    143157 
     
    145159        dh $@ 
    146160}}} 
    147      * You can have pre- and post- install scripts 
     161   * Debhelper modules are mostly configured through files in `debian/` named `module` (or `package.module` when building multiple packages). 
     162     * You can have pre- and post- install scripts by creating `debian/preinst` etc. (man `dh_installdeb`) 
    148163   * For a python package, you just need a few files (those mentioned above) 
    149164   * `dch` lets you edit `debian/changelog` 
    150165   * To install scripts, create a little script that loads the module (`debian/hellopy`) and add the instruction to install in `debian/install`: `debian/hellopy /usr/bin` 
    151    * Call the package `python-$libname` to follow convention 
    152    * `Architecture`: `any` means build on every architecture; `all` means just build one package for all libraries 
    153    * `Description` - first line is summary, the rest is detail 
    154    * Format is the same as email: To continue on a new line, put a space as the first character; for a blank line use `<space><dot>` like so: ` .` 
    155    * `XS-Python-Version`: You can set this to `all` or limit to greater than `2.5` etc 
    156    * `Depends`: calls the macro `${python_Depends}` 
    157166 * There are two competing ways to do python dependencies on debian: `python-central` and `python-support` 
    158167   * `python-central` is maintained by the Python maintainer, used by 10-20% of the packages. 
    159168   * `python-support` is much more popular, and the maintainer is more reactive. Integrates nicely with `debhelper 7` 
    160    * Specify `Build-Depends: debhelper (>= 7), python-support` 
    161169 * Patching the source directly is frowned upon, there are systems for managing patches 
    162    * Put `3.0 (quilt)` in `debian/source/format` and then you can use `quilt` to maintain patches 
    163  * Then you build with `debuild`: 
     170   * Put `3.0 (quilt)` in `debian/source/format` and then you can use `quilt` to maintain patches in `debian/patches` 
     171   * Source format 3.0 gives you a `.debian.tar.gz` instead of a `.diff.gz` containing the debian additions to a package. 
     172 * Then you build with `debuild -uc -us`: 
    164173   * Your package should automatically clean everything it creates - `clean` gets run before `build` 
    165    * Everything gets installed under a fake root, so you need to specify anything that your build requires 
    166    * `debc` lists the contents of the deb file 
     174   * Debian builds packages in an empty chroot, so you need to specify anything non-essential that your build requires. Test this with pbuilder / Launchpad PPAs. 
     175   * `debc` lists the contents of the deb file just built. 
     176   * `linitan -Ivi --pedantic ../*.build` will tell you what you did wrong. 
    167177 * Then you install... 
    168178   * As you install, `python-support` will automatically byte compile your python code for you by calling `update-python-modules` 
    169179   * `/usr/lib/pymodules/python2.x` contains symlinks to the original code under `/usr/share/pyshared/` as well as the byte-compiled files for that version 
    170180   * Extensions go into `/usr/lib/python-support/python-$libname/python2.x/` 
    171    * These symlinks and byte-compiled files aren't actually owned by the package, but will be regenerated/cleaned up if you run `update-python-modules` for that package again 
     181   * These symlinks and byte-compiled files aren't actually owned by the package, but will be regenerated/cleaned up if you run `update-python-modules` for that package again. 
     182   * All data files should go into `/usr/share/$package`. 
     183   * If you are packaging an application rather than a library, you shouldn't install into the global Python namespace, but rather into `/usr/share/$package`, with appropriate modifications to the scripts. 
    172184 * More advanced ideas: 
    173    * You now don't have to have a `.diff.gz` containing the debian additions to a package, you can use `.debian.tar.gz` containing them instead 
    174    * A lot of the packaging work is being pedantic, making sure it will be correct no matter who runs it 
     185   * A lot of the packaging work is being pedantic, making sure it will be correct no matter who runs it. 
    175186   * You can override `dh` rules in `debian/rules` to do things like adjusting automatic compression of files 
    176  * To get your package into Debian, hop onto the `debian-python` IRC channel and ask for someone to help - they'll check through your package and hlpe you fix mistakes 
     187 * To get your package into Debian, hop onto the `#debian-python` IRC channel on OFTC and ask for someone to help - they'll check through your package and hlpe you fix mistakes. (Or ping tumbleweed). 
    177188 
    178189== Future of Python packaging ==