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]

Reply via email to