Changes between Version 10 and Version 11 of TalkPackaging


Ignore:
Timestamp:
Mar 13, 2010, 5:41:09 PM (11 years ago)
Author:
Stefano Rivera
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 ==