Deb-pkg-tools

----------------------------

Improve implementation and documentation of ``collect_related_packages()``.

The result of the old implementation was dependent on the order of entries
returned from ``os.listdir()`` which can differ from system to system (say my
laptop vervsus Travis CI) and so caused inconsistently failing builds.

.. _Release 1.32: https://github.com/xolox/python-deb-pkg-tools/compare/1.31...1.32

----------------------------

- Extracted installed version discovery to re-usable function.
- ``dpkg-scanpackages`` isn't used anymore, remove irrelevant references.

.. _Release 1.31: https://github.com/xolox/python-deb-pkg-tools/compare/1.30...1.31

----------------------------

Added ``deb_pkg_tools.utils.find_debian_architecture()`` function.

This function is currently not used by deb-pkg-tools itself but several of my
projects that build on top of deb-pkg-tools need this functionality and all of
them eventually got their own implementation. I've now decided to implement
this once, properly, so that all projects can use the same tested and properly
documented implementation (as simple as it may be).

.. _Release 1.30: https://github.com/xolox/python-deb-pkg-tools/compare/1.29.4...1.30

------------------------------

Adapted pull request `5`_ to restore Python 3 compatibility.

.. _Release 1.29.4: https://github.com/xolox/python-deb-pkg-tools/compare/1.29.3...1.29.4
.. _5: ttps://github.com/xolox/python-deb-pkg-tools/pull/5

------------------------------

Changed SQLite row factory to "restore" Python 3.4.2 compatibility.

The last Travis CI builds that ran on Python 3.4.1 worked fine and no changes
were made in deb-pkg-tools since then so this is clearly caused by a change in
Python's standard library. This is an ugly workaround but it's the most elegant
way I could find to "restore" compatibility.

.. _Release 1.29.3: https://github.com/xolox/python-deb-pkg-tools/compare/1.29.2...1.29.3

------------------------------

Bug fix: Don't normalize ``Depends:`` lines.

Apparently ``dpkg-scanpackages`` and compatible re-implementations like the one
in deb-pkg-tools should not normalize ``Depends:`` fields because apt can get
confused by this. Somehow it uses either a literal comparison of the metadata
or a comparison of the hash of the metadata to check if an updated package is
available (I tried to find this in the apt sources but failed to do so due to
my limited experience with C++). So when the ``Depends:`` line in the
``Packages.gz`` file differs from the ``Depends:`` line in the binary control
file inside a ``*.deb`` apt will continuously re-download and install the same
binary package...

.. _Release 1.29.2: https://github.com/xolox/python-deb-pkg-tools/compare/1.29.1...1.29.2