Deb-pkg-tools

Latest version: v8.3

Safety actively analyzes 629678 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 2 of 25

6.0

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

- Enable compatibility with newer python-apt_ releases:

- The test suite has been modified to break on Travis CI when python-apt_
should be available but isn't (when the Python virtual environment is based
on a Python interpreter provided by Ubuntu, currently this applies to all
build environments except Python 3.7).

- The idea behind the test suite change is to verify that the conditional
import chain in ``version.py`` always succeeds (on Travis CI, where I
control the runtime environment).

- This was added when after much debugging I finally realized why the new
Ubuntu 18.04 build server I'd created was so awfully slow: The conditional
import chain had been "silently broken" without me realizing it, except for
the fact that using the fall back implementation based on ``dpkg
--compare-versions`` to sort through thousands of version numbers was
rather noticeably slow... 😇

- Make python-memcached_ an optional dependency in response to `13`_.

- Dropped Python 2.6 compatibility.

.. _Release 6.0: https://github.com/xolox/python-deb-pkg-tools/compare/5.2...6.0
.. _python-memcached: https://pypi.org/project/python-memcached
.. _13: https://github.com/xolox/python-deb-pkg-tools/issues/13

5.2

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

Promote python-debian version constraint into a conditional dependency.

Recently I constrained the version of python-debian to work around a Python 2.6
incompatibility. This same incompatibility is now biting me in the `py2deb
setup on Travis CI`_ and after fighting that situation for a while I decided it
may be better (less convoluted) to fix this in deb-pkg-tools instead (at the
source of the problem, so to speak).

.. _Release 5.2: https://github.com/xolox/python-deb-pkg-tools/compare/5.1.1...5.2
.. _py2deb setup on Travis CI: https://github.com/paylogic/py2deb/compare/4284a1db99699bab14bc5fb62a88256a5d1ae978...60ece9ffebbd5f1bdff7ea20fbf0eeb401a9da3f

5.1.1

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

Bug fix for logic behind ``deb_pkg_tools.GPGKey.existing_files`` property: The
configured ``directory`` wasn't being scanned in combination with GnuPG < 2.1
even though the use of ``directory`` has become the preferred way to configure
GnuPG < 2.1 as well as GnuPG >= 2.1 (due to the GnuPG bug mentioned in the
release notes of release 5.1).

.. _Release 5.1.1: https://github.com/xolox/python-deb-pkg-tools/compare/5.1...5.1.1

5.1

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

Added the ``deb_pkg_tools.gpg.GPGKey.identifier`` property that uses the ``gpg
--list-keys --with-colons`` command to introspect the key pair and extract a
unique identifier:

- When a fingerprint is available in the output this is the preferred value.
- Otherwise the output is searched for a key ID.

If neither of these values is available an exception is raised.

.. note:: While testing this I noticed that the old style ``gpg
--no-default-keyring --keyring=… --secret-keyring=…`` commands don't
support the ``--list-keys`` command line option. The only workaround
for this is to use the ``directory`` property (which triggers the use
of ``--homedir``) instead of the ``public_key_file`` and
``secret_key_file`` properties. This appears to be due to a bug in
older GnuPG releases (see `this mailing list thread`_).

.. _Release 5.1: https://github.com/xolox/python-deb-pkg-tools/compare/5.0...5.1
.. _this mailing list thread: https://lists.gnupg.org/pipermail/gnupg-users/2002-March/012144.html

5.0

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

**GnuPG >= 2.1 compatibility for repository signing.**

This release became rather more involved than I had hoped it would 😇 because
of backwards incompatibilities in GnuPG >= 2.1 that necessitated changes in the
API that deb-pkg-tools presents to its users:

- The ``--secret-keyring`` option has been obsoleted and is ignored and
the suggested alternative is the use of an `ephemeral home directory`_ which
changes how a key pair is specified.

- This impacts the API of the ``deb_pkg_tools.gpg.GPGKey`` class as well as
the ``repos.ini`` support in ``deb_pkg_tools.repo.update_repository()``.

The documentation has been updated to explain all of this, refer to the
``deb_pkg_tools.gpg`` module for details. Detailed overview of changes:

- The ``deb_pkg_tools.gpg.GPGKey`` class is now based on ``property-manager``
and no longer uses instance variables, because this made it easier for
me to split up the huge ``__init__()`` method into manageable chunks.

A side effect is that ``__init__()`` no longer supports positional
arguments which technically speaking is **backwards incompatible**
(although I never specifically intended it to be used like that).

- The ``deb_pkg_tools.gpg.GPGKey`` class now raises an exception when it
detects that the use of an isolated key pair is intended but the
``directory`` option has not been provided even though GnuPG >= 2.1 is
being used. While this exception is new, the previous behavior on
GnuPG >= 2.1 was anything but sane, so any thoughts about the
backwards compatibility of this new exception are a moot point.

- The ``deb_pkg_tools.gpg.GPGKey`` used to raise ``TypeError`` when a key pair
is explicitly specified but only one of the two expected files exists, in
order to avoid overwriting files not "owned" by deb-pkg-tools. An exception
is still raised but the type has been changed to ``EnvironmentError`` because
I felt that it was more appropriate. This is technically **backwards
incompatible** but I'd be surprised if this affects even a single user...

- The repository activation fall back test (that generates an automatic
signing key in order to generate ``Release.gpg``) was failing for me on
Ubuntu 18.04 and in the process of debugging this I added support for
``InRelease`` files. In the end this turned out to be irrelevant to the
issue at hand, but I saw no harm in keeping the ``InRelease`` support.
This is under the assumption that the presence of an ``InRelease`` file
shouldn't disturb older ``apt-get`` versions (which seems like a sane
assumption to me - it's just a file on a webserver, right?).

- Eventually I found out that the repository activation fall back test
was failing due to the key type of the automatic signing key that's
generated during the test: As soon as I changed that from DSA to RSA
things started working.

- GnuPG profile directory initialization now applies 0700 permissions to
avoid noisy warnings from GnuPG.

- Added Python 3.7 to tested and and supported versions.

- Improved ``update_repository()`` documentation.

- Moved function result caching to ``humanfriendly.decorators``.

- I've changed ``Depends`` to ``Recommends`` in ``stdeb.cfg``, with the
following rationale:

- The deb-pkg-tools package provides a lot of loosely related functionality
depending on various external commands. For example building of Debian
binary packages requires quite a few programs to be installed.

- But not every use case of deb-pkg-tools requires all of these external
commands, so demanding that they always be installed is rather inflexible.

- In my specific case this dependency creep blocked me from building
lightweight tools on top of deb-pkg-tools, because the dependency chain
would pull in a complete build environment. That was more than I bargained
for when I wanted to use a few utility functions in deb-pkg-tools 😅.

- With this change, users are responsible for installing the appropriate
packages. But then I estimate that less than one percent of my users are
actually affected by this change, because of the low popularity of
solutions like stdeb_ and py2deb_ 😇.

- Only the python-apt_ package remains as a strict dependency instead of a
recommended dependency, see 757286fc8ce_ for the rationale.

- Removed python-apt_ intersphinx reference (`for now
<https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1799807>`_).

- Added this changelog to the repository and documentation.

.. _Release 5.0: https://github.com/xolox/python-deb-pkg-tools/compare/4.5...5.0
.. _stdeb: https://pypi.org/project/stdeb/
.. _ephemeral home directory: https://www.gnupg.org/documentation/manuals/gnupg/Ephemeral-home-directories.htmlEphemeral-home-directories
.. _757286fc8ce: https://github.com/xolox/python-deb-pkg-tools/commit/757286fc8ce
.. _python-apt: https://packages.debian.org/python-apt

4.5

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

Improved robustness of ``dpkg-shlibdeps`` and ``strip`` integration (followup
to `release 4.4`_).

.. _Release 4.5: https://github.com/xolox/python-deb-pkg-tools/compare/4.4...4.5

Page 2 of 25

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.