Changes between Version 10 and Version 11 of TalkPackaging

Timestamp:

Mar 13, 2010, 5:41:09 PM (14 years ago)

Author:

stefanor

Comment:

things I should have said :)

TalkPackaging

@@ -126 +126 @@
 === The world of Debian ===
 
+ * Install `devscripts`, `python-support` and `build-essential`.
+   * To download the sample package, you can run:
+{{{
+dget -xu http://ctpug.org.za/raw-attachment/wiki/TalkPackaging/hellopy_1.9-1.dsc
+}}}
  * Package your source up nicely using `sdist`
  * Things get named `name_version.orig.tar.gz`
+   * You can use `uscan` to download, repack, and rename it for you if you create a `debian/watch` file appropriately. You should do this.
  * Unpack the source distribution, and run `dh_make`
+   * Go for `single binary` mode. It's the simplest.
  * Look through the different example files that are produced:
    * There are loads of them, you don't have to use all of them
    * `debian/control` tells what different packages should be produced
-     * You can have separate `binary` and `source` files
-   * `debian/copyright` is important to signal the licenses etc, following Debian rules
+     * 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.
+     * Call the binary package `python-$libname` to follow convention
+     * `Architecture`: `any` means build on every architecture; `all` means just build one package for all architectures (pure python).
+     * `Description` - first line is summary, the rest is detail
+     * 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: ` .`
+     * `XS-Python-Version`: You can set this to `all` or `>= 2.5`, etc. (`/usr/share/doc/python-support/README.gz`)
+     * 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.
+     * `Depends`: calls the macro `${python_Depends}`
+   * `debian/copyright` is important to signal the licenses etc, following Debian rules.
+     * You can use [http://dep.debian.net/deps/dep5/ DEP5 format] or prose.
    * `debian/rules` is a makefile that generates a deb
-     * It's a lot of work to write all the rules, so there are a lot of helper tools
+     * It's a lot of work to write all the rules, so there are a lot of helper tools: debhelper, cdbs, dh (debhelper 7)
      * This used to involve lots of separate build steps
      * debhelper 7 is the way to go nowadays... Now you just use `dh`:
 {{{
-
 #!/usr/bin/make -f
 
@@ -145 +159 @@
         dh $@
 }}}
-     * You can have pre- and post- install scripts
+   * Debhelper modules are mostly configured through files in `debian/` named `module` (or `package.module` when building multiple packages).
+     * You can have pre- and post- install scripts by creating `debian/preinst` etc. (man `dh_installdeb`)
    * For a python package, you just need a few files (those mentioned above)
    * `dch` lets you edit `debian/changelog`
    * 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`
-   * Call the package `python-$libname` to follow convention
-   * `Architecture`: `any` means build on every architecture; `all` means just build one package for all libraries
-   * `Description` - first line is summary, the rest is detail
-   * 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: ` .`
-   * `XS-Python-Version`: You can set this to `all` or limit to greater than `2.5` etc
-   * `Depends`: calls the macro `${python_Depends}`
  * There are two competing ways to do python dependencies on debian: `python-central` and `python-support`
    * `python-central` is maintained by the Python maintainer, used by 10-20% of the packages.
    * `python-support` is much more popular, and the maintainer is more reactive. Integrates nicely with `debhelper 7`
-   * Specify `Build-Depends: debhelper (>= 7), python-support`
  * Patching the source directly is frowned upon, there are systems for managing patches
-   * Put `3.0 (quilt)` in `debian/source/format` and then you can use `quilt` to maintain patches
- * Then you build with `debuild`:
+   * Put `3.0 (quilt)` in `debian/source/format` and then you can use `quilt` to maintain patches in `debian/patches`
+   * Source format 3.0 gives you a `.debian.tar.gz` instead of a `.diff.gz` containing the debian additions to a package.
+ * Then you build with `debuild -uc -us`:
    * Your package should automatically clean everything it creates - `clean` gets run before `build`
-   * Everything gets installed under a fake root, so you need to specify anything that your build requires
-   * `debc` lists the contents of the deb file
+   * 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.
+   * `debc` lists the contents of the deb file just built.
+   * `linitan -Ivi --pedantic ../*.build` will tell you what you did wrong.
  * Then you install...
    * As you install, `python-support` will automatically byte compile your python code for you by calling `update-python-modules`
    * `/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
    * Extensions go into `/usr/lib/python-support/python-$libname/python2.x/`
-   * 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
+   * 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.
+   * All data files should go into `/usr/share/$package`.
+   * 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.
  * More advanced ideas:
-   * 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
-   * A lot of the packaging work is being pedantic, making sure it will be correct no matter who runs it
+   * A lot of the packaging work is being pedantic, making sure it will be correct no matter who runs it.
    * You can override `dh` rules in `debian/rules` to do things like adjusting automatic compression of files
- * 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
+ * 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).
 
 == Future of Python packaging ==