Bug#894027: stretch-pu: package addresses-for-gnustep/0.4.8-2+deb9u1
Julien Cristau wrote:
> On Sun, Mar 25, 2018 at 17:00:43 +0300, Yavor Doganov wrote:
> > If possible, I would like to fix #889534 and #889536 (missing
> > dependencies).
> What does this translate to in terms of changes to binary packages?
Needed libraries added to Depends:, here are the binary debdiffs:
$ debdiff libaddresses0_0.4.8-2+b2_i386.deb libaddresses0_0.4.8-2+deb9u1_i386.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/share/doc/libaddresses0/changelog.Debian.i386.gz
Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: libc6 (>= 2.4), libgcc1 (>= [-1:3.0)-] {+1:3.0), libgnustep-base1.24 (>= 1.24.7), libobjc4 (>= 4.2.1)+}
Installed-Size: [-269-] {+268+}
Source: addresses-for-gnustep [-(0.4.8-2)-]
Version: [-0.4.8-2+b2-] {+0.4.8-2+deb9u1+}
$ debdiff libaddressview0_0.4.8-2+b2_i386.deb libaddressview0_0.4.8-2+deb9u1_i386.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/share/doc/libaddressview0/changelog.Debian.i386.gz
Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: {+gnustep-back0.25, gnustep-gui-runtime, libaddresses0 (>= 0.4.6),+} libc6 (>= [-2.4)-] {+2.4), libgnustep-base1.24 (>= 1.24.7), libgnustep-gui0.25, libobjc4 (>= 4.2.1)+}
Installed-Size: [-295-] {+294+}
Source: addresses-for-gnustep [-(0.4.8-2)-]
Version: [-0.4.8-2+b2-] {+0.4.8-2+deb9u1+}
> Is this an issue for users in practice, or mainly a
> theoretical/correctness issue?
I would say it's the latter. Any program linking against libaddresses
or libaddressview presumably already links with gnustep-base/gui and
the Objective-C runtime. There are cases when the dynamic linker
loads the libraries in the wrong order which may lead to runtime
failure if loadable modules (bundles) are not linked properly. But I
haven't seen this in practice and I'd say it's unlikely to occur on
modern systems.
Reply to: