Your message dated Wed, 24 Aug 2011 09:38:19 +0200
with message-id <[email protected]>
and subject line Fixed in pcre3 8.12-4
has caused the Debian Bug report #616660,
regarding /usr/bin/pcretest must not be shipped in libpcre3
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
616660: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616660
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libpcre3
Version: 8.02-1.1
Severity: serious
User: [email protected]
Usertags: multiarch
Hi Mark,
The /usr/bin/pcretest executable in the libpcre3 is a violation of Policy 8.2:
If your package contains files whose names do not change with each
change in the library shared object version, you must not put them in
the shared library package. Otherwise, several versions of the shared
library cannot be installed at the same time without filename clashes,
making upgrades and transitions unnecessarily difficult.
[...]
Run-time support programs that use the shared library but are not
required for the library to function or files used by the shared
library that can be used by any version of the shared library package
should instead be put in a separate package. This package might
typically be named `<libraryname>-tools'; note the absence of the
<soversion> in the package name.
Of course libpcre has a very, very stable ABI so it's possible we will never
have to worry about a new soname (and this explains why no one has worried
about this policy violation before now), but with multiarch finally coming
around, a library package that ships a binary in /usr/bin doesn't only
conflict with a different soname of the same library, it also conflicts
with the *same* library from a different architecture.
IMHO it doesn't make sense to create a -tools package just for pcretest,
especially given the lukewarm justification for including the executable
that's given in bug #162998. Perhaps this executable could be moved to the
pcregrep package, or else maybe it should just be dropped?a
-- System Information:
Debian Release: 6.0
APT prefers oldstable
APT policy: (500, 'oldstable'), (500, 'stable')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.30-1-iop32x
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libpcre3 depends on:
ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib
libpcre3 recommends no packages.
libpcre3 suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Package: pcre3
Version: 8.12-4
The latest upload of pcre3 dropped the pcretest binary, and I have
verified that multiple versions of libpcre3 are actually coinstallable:
,----
| Selecting previously unselected package libpcre3.
| (Reading database ... 9339 files and directories currently installed.)
| Unpacking libpcre3 (from .../libpcre3_8.12-4_i386.deb) ...
| Selecting previously unselected package libpcre3:amd64.
| Unpacking libpcre3:amd64 (from .../libpcre3_8.12-4_amd64.deb) ...
| Setting up libpcre3:amd64 (8.12-4) ...
| Setting up libpcre3 (8.12-4) ...
`----
--- End Message ---
