> apt-listbugs alerted me to this bug when I attempted to upgrade from > 1.2.0-1.4. I can't tell from the information provided: if I upgrade to > an affected version, should I expect things on my system to break?
I pinned the package, subscribed the bug and think it's good to have some traffic in here. (Which of course will not fix the problem) With a bit of luck, someone with knowledge tells ushow a proper solution would look like. Maybe this is useful, anyway there is a lot to read and learn: * http://kernel-handbook.alioth.debian.org/ch-versions.html * http://ispras.linuxbase.org/index.php/ABI_compliance_checker * http://wiki.debian.org/Teams/ReleaseTeam/Transitions * http://wiki.debian.org/Teams/ReleaseTeam > Abi compliance checker > http://ispras.linux-foundation.org/index.php/ABI_compliance_checker > abi-compliance-checker can be used to help reduce the possibility of > an application crashing when the shared libraries it links against > have changed. Signatures and data type definitions from two separate > versions of a library are compared by examining the shared objects > (.so) files themselves, and by analysing the header files (.h) > provided for the two versions of the library and their dependencies. > Shared library developers trying to strive for binary compatibility > between releases may also use this tool to detect if an any > accidental application binary interface (ABI) changes have been > introduced. The checker may also be used for assessing binary > compatibility between different Linux distributions. gpgme1.0 (1.4.1-0.1) unstable; urgency=low * debian/control: Enable multiarch support (closes: #698970). (Priority): Raised to standard (closes: #623353). (Section): Changed to libs. Fixed binary-control-field-duplicates-source. (Standards-Version): Bumped to 3.9.4. (Vcs-Git, Vcs-Browser): Adjusted to point to svn tree (closes: #610737). (Build-Depends, Depends): Added new dependencies including libassuan-dev. Fixed debhelper-but-no-misc-depends. Dropped dpatch and obsolete libpth-dev. Replaced gnupg by gnupg2. (Description): Fixed several lintian hints. * debian/libgpgme11.files: Renamed to debian/libgpgme11.install, adjusted. * debian/libgpgme11-dev.files: Likewise. Dropped .la (LP: #728497). * debian/libgpgme11.dirs, debian/libgpgme11-dev.dirs: Dropped useless files. * debian/libgpgme11-dev.info: Ditto. * debian/libgpgme11-dev.doc-base (Section): Fixed. * debian/libgpgme11.symbols: Updated. Removed symbols of libgpgme-pth.so.11. -- Daniel Leidert <dleid...@debian.org> Tue, 14 May 2013 20:29:20 +0200 < http://wiki.debian.org/ReleaseTeamOverloaded I think that part of the problem is that we're leaning on the release team to make hard decisions that we should be capable of making ourselves. -- JoeyHess Read debian-release, you'll frequently see developers: * Say: "can this <random change> get into sarge?" * Trying to get in a change without thinking it through. * It's also annoyingly common for maintainers to upload a fix that really needs to get into sarge with other nonessential changes that increase the probability a bug will be introduced * Upload something such as a security fix with a priority that's too low * Package a new upstream version of a library in a way that it holds lots of other things out of sarge. All of these are responsible for a lot of the load on the release team. All can be avoided by maintainers thinking through the conseqences. -- JoeyHess -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
