Package: fam Version: 2.7.0-8 Severity: serious The current libfam0 provides the previous libfam0c102, presumably because libfam is a C++ lib but only exports a C interface, so the transition for GCC 4 was unnecessary.
However, the libfam0c102 in sarge provides libfam0. This means that that package completely satisfies any package in etch that depends on libfam0 (with the exception of those that have a versioned dependency on libfam0, like libfam-dev). The consequence is that an "apt-get dist-upgrade" or equivalent will *not* install libfam0 but will keep libfam0c102 around instead. This would be very bad for security, since most sarge users upgrading to etch would never get libfam0 updates as their system is silently content with the obsolete libfam0c102. Also, I just noticed in aptitude that it found both libfam0 and libfam0c102 both conflicted with each other, and thus refused to continue unless I chose one in favor over the other. This is an exceedingly odd situation. The only solution that seems satisfactory to me is to go back to the sarge-style packaging, meaning kill the libfam0 package and re-introduce libfam0c102. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.12.4 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages fam depends on: ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-6 GCC support library ii libstdc++6 4.0.1-6 The GNU Standard C++ Library v3 Versions of packages fam recommends: ii portmap 5-15 The RPC portmapper -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]