Pkg exim4 users - Dec 2005 - libmysqlclient.so: no version information available

Since upgrading to version 4.54 Exim complains
"/usr/lib/libmysqlclient.so.14: no version information available (required
by /usr/sbin/exim4)".
The same with version 4.60.

Here some more infos:

# dpkg -l|grep libmysqlclient
ii  libmysqlclient 3.23.56-3      LGPL-licensed client library for MySQL
datab
ii  libmysqlclient 4.0.24-10sarge mysql database client library
ii  libmysqlclient 4.1.11a-4sarge mysql database client library

# locate libmysqlclient.so
/usr/lib/libmysqlclient.so.10
/usr/lib/libmysqlclient.so.10.0.0
/usr/lib/libmysqlclient.so.12
/usr/lib/libmysqlclient.so.12.0.0
/usr/lib/libmysqlclient.so.14
/usr/lib/libmysqlclient.so.14.0.0

I''m not using mysql features with exim and it seems to run fine anyway.
Are there any hints how to get rid of this message?

hjb :-?
-- 
Hans-Juergen Beie
hjb@pollux.franken.de

On 2005-12-02 Hans-Juergen Beie <hjb@pollux.franken.de>
wrote:
> Since upgrading to version 4.54 Exim complains
> "/usr/lib/libmysqlclient.so.14: no version information available
(required
> by /usr/sbin/exim4)".
> The same with version 4.60.
> Here some more infos:
> # dpkg -l|grep libmysqlclient
> ii  libmysqlclient 3.23.56-3      LGPL-licensed client library for MySQL
> datab
> ii  libmysqlclient 4.0.24-10sarge mysql database client library
> ii  libmysqlclient 4.1.11a-4sarge mysql database client library
[...]
> I''m not using mysql features with exim and it seems to run fine
anyway.
> Are there any hints how to get rid of this message?
Are you running a mixed sarge/etch/sid system?

   cu and- I think libmysqlclient14 4.1.14-3 should have
           bumped shlibs -reas
-- 
The ''Galactic Cleaning'' policy undertaken by Emperor Zhark is
a personal
vision of the emperor''s, and its inclusion in this work does not
constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

Andreas Metzler wrote on 03.12.2005 11:32:
> On 2005-12-02 Hans-Juergen Beie <hjb@pollux.franken.de> wrote:
> 
>>Since upgrading to version 4.54 Exim complains
>>"/usr/lib/libmysqlclient.so.14: no version information available
(required
>>by /usr/sbin/exim4)".
>>The same with version 4.60.
> 
> 
>>Here some more infos:
> 
> 
>># dpkg -l|grep libmysqlclient
>>ii  libmysqlclient 3.23.56-3      LGPL-licensed client library for MySQL
>>datab
>>ii  libmysqlclient 4.0.24-10sarge mysql database client library
>>ii  libmysqlclient 4.1.11a-4sarge mysql database client library
> 
> [...]
> 
>>I''m not using mysql features with exim and it seems to run fine
anyway.
>>Are there any hints how to get rid of this message?
> 
> 
> Are you running a mixed sarge/etch/sid system?
Yes. Otherwise newer releases of Exim and ClamAV won''t install.
>    cu and- I think libmysqlclient14 4.1.14-3 should have
>            bumped shlibs -reas
Good point, many thanks!

I raised the pinning for libmysqlclient14 to testing and Exim doesn''t 
complain anymore. To satisfy the dependencies I had to choose 
release=testing for mysql-common, too. But this doesn''t hurt me,
because
I don''t use it anyway.

If somebody has similar problems, this is what I did:

I included this into /etc/apt/preferences

   Package: mysql-common
   Pin: release a=testing
   Pin-Priority: 800

   Package: libmysqlclient14
   Pin: release a=testing
   Pin-Priority: 800 


After upgrading ....

   # apt-get update
   # ### see what will happen...
   # apt-get -su install libmysqlclient14
   # ### if it looks good, do it!
   # apt-get -u install libmysqlclient14

.... I got

   # dpkg -l|grep mysql
   ii  libmysqlclient 3.23.56-3      LGPL-licensed client library for ...
   ii  libmysqlclient 4.0.24-10sarge mysql database client library
   ii  libmysqlclient 4.1.14-6       mysql database client library
   ii  mysql-common   5.0.13rc-1     mysql database common files ... 


Another way to do it without pinning, might be to use the dotdeb 
packages (www.dotdeb.org). But I tried it only up to the ''apt-get
-su''
point. It seems to end with similar results.

Have a nice day.

hjb :-?

me getting OT:
>> Are you running a mixed sarge/etch/sid system?
>
>
> Yes. Otherwise newer releases of Exim and ClamAV won''t install.
btw:  since stable "only" has security fixes, how much will a current 
(upstream)  ClamAV, SpamAssassin e.a. will drift away from stable? What 
i mean: security fixes won''t install new scan engines (does this occur 
in "real world"?), but only programming errors, or maybe some scanning
patterns, too. So, won''t i be forced in time to change a stable system 
(which is what i want in poduction environment) to a mixed system with 
testing or sid? Which would/could cause update problems and potentially 
instabel or (more) insceure system? Won''t aging of these scanning tools
render them quite worthless?

How do YOU deal with this? Suggested Readme''s, HowTo''s? Is
there some
missconception in my mind?

Gerhard

ps: still rampant learning curve ahead, for running mailserver; don''t 
yet use clamav/sa

On 2005-12-03 Hans-Juergen Beie <hjb@pollux.franken.de>
wrote:
> Andreas Metzler wrote on 03.12.2005 11:32:
>>On 2005-12-02 Hans-Juergen Beie <hjb@pollux.franken.de> wrote:
>>>Since upgrading to version 4.54 Exim complains
>>>"/usr/lib/libmysqlclient.so.14: no version information
available (required
>>>by /usr/sbin/exim4)".
>>>The same with version 4.60.
[...]
>> Are you running a mixed sarge/etch/sid system?
> Yes. Otherwise newer releases of Exim and ClamAV won''t install.
>>   cu and- I think libmysqlclient14 4.1.14-3 should have
>>           bumped shlibs -reas
> Good point, many thanks!
> I raised the pinning for libmysqlclient14 to testing and Exim
doesn''t
> complain anymore.
Thanks for the confirmation, submitted as http://bugs.debian.org/341819
              cu andreas
-- 
The ''Galactic Cleaning'' policy undertaken by Emperor Zhark is
a personal
vision of the emperor''s, and its inclusion in this work does not
constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

On 2005-12-03 Gerhard Kroder <gerhard.kroder@t-online.de>
wrote:
> me getting OT:
[...]
> >Yes. Otherwise newer releases of Exim and ClamAV won''t
install.
> btw:  since stable "only" has security fixes, how much will a
current
> (upstream)  ClamAV, SpamAssassin e.a. will drift away from stable? What 
> i mean: security fixes won''t install new scan engines (does this
occur
> in "real world"?), but only programming errors, or maybe some
scanning
> patterns, too. So, won''t i be forced in time to change a stable
system
> (which is what i want in poduction environment) to a mixed system with 
> testing or sid? Which would/could cause update problems and potentially 
> instabel or (more) insceure system? Won''t aging of these scanning
tools
> render them quite worthless?
> How do YOU deal with this?
[...]

Current clamav for sarge is availble on volatile.
deb http://ftp2.de.debian.org/debian-volatile sarge/volatile main

Current spamassassin will probaly soon be available on volatile

Current exim4 for sarge will soon be available on backports.org. (4.54
is in in the pending directory, 4.60 will follow soon. Once the dak
setup on backports.org is finished the packages will propagate to the
regular backports.org repository.) Newest latest clamav and
spamassassin should work fine with sarge''s exim4, BTW.
               cu andreas
-- 
The ''Galactic Cleaning'' policy undertaken by Emperor Zhark is
a personal
vision of the emperor''s, and its inclusion in this work does not
constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

Gerhard Kroder wrote on 03.12.2005 13:23 Uhr:
> me getting OT:
well... new topic ;)
>>> Are you running a mixed sarge/etch/sid system?
>>
>> Yes. Otherwise newer releases of Exim and ClamAV won''t
install.
> 
> 
> btw:  since stable "only" has security fixes, how much will a
current
> (upstream)  ClamAV, SpamAssassin e.a. will drift away from stable? What 
> i mean: security fixes won''t install new scan engines (does this
occur
> in "real world"?), but only programming errors, or maybe some
scanning
> patterns, too. So, won''t i be forced in time to change a stable
system
> (which is what i want in poduction environment) to a mixed system with 
> testing or sid? Which would/could cause update problems and potentially 
> instabel or (more) insceure system? Won''t aging of these scanning
tools
> render them quite worthless?
> 
> How do YOU deal with this? Suggested Readme''s, HowTo''s?
Is there some
> missconception in my mind?
 >
> Gerhard
> 
> ps: still rampant learning curve ahead, for running mailserver;
don''t
> yet use clamav/sa
What is "stable"?
- Bug-free software? That''s a dream.

- Bug-fixed software? OK (one bug fixed, get tow more for free ;)

- Debain/sarge? Hmm... that depends...

What is "secure"?
- A rock solid server, resistant against all known root kits, intrusion 
methods and script kiddies? From a admin''s point of view it may be 
"secure". But that''s often an end in itself.

- A system which provides a much security as possible for its users? 
Fine... but what about the rest of the world arround?

Nowadays, a "stable" and "secure" mail server is something
what we would
call "die Quadratur des Kreises" in german. That''s my
experience, still
on the learming curve after trying to administrate some small mail 
servers on RedHat/Fedora and Debian hosts for some years now.

Comming back to debian/exim/clamav/sa ...

When I had to setup a (still small) production system for the first 
time, I decided (after reading many of these Readmes, HowTotos, and 
FAQs) to choose Exim4 on debian/stable (woody at that time) as a basis 
and to provide the necessary environment by pinning (woody still sticked 
to Exim3) or by using backports. This method was also suitable to get 
recent versions of ClamAV and SA up and running, on so-called "stable"
debian flavours. Now with debian/sarge, this is quite similar.

I should mension however, that this host (in fact it''s a VServer) makes
nothing else than delivering and providing mail (Web an database 
applications are running on other hosts/VServers). That gives me the 
freedom to choose those packages which I believe to be most suitable for 
this purpose without getting headache because of possible side-effects 
on other applications. And I sweared never to compile or build packages 
myself. Fortunately, I never had to break my word, up to now (at least 
concerning the mail server ;)

I won''t never claim that this system is "stable" as well as
"secure".
It''s just a compromise somewhere between.

That''s how I deal with it.
Your mileage may vary.

hjb :-?

Andreas Metzler wrote:
>On 2005-12-03 Gerhard Kroder <gerhard.kroder@t-online.de> wrote:
>  
>
>>me getting OT:
>>    
>>
>[...]
>  
>
>
>>How do YOU deal with this?
>>    
>>
>[...]
>
>Current clamav for sarge is availble on volatile.
>deb http://ftp2.de.debian.org/debian-volatile sarge/volatile main
>  
>
uuh, haven''t heard of "volatile" ''till now. sounds
interesting.
>Once the dak
>setup on backports.org is finished the packages will propagate to the
>regular backports.org repository.)
>
Good to have alternatives, and i consider making use of them. But, as 
side effect, we step out of the "stable" concept for productive 
environments, don''t we? With no basic "in time" security
updates? I
really appreciate people supplying backports, sideports and other 
repositories, and i know they support this as far as possible. But this 
probably less standardized as "regular security support".

Have there been any efforts/ideas to prevent this split-ups? There 
schould be significant demand from users running "stable" servers,  
needing stabel _and_ current services like exim e.a. I''m shure this is 
an issue. Has it been addressed before in Debian community? I know 
software is somtimes a fast moving target, especially in the line of 
network and security. And this is contrary to the stable concept and the 
underlying time-span realized by Debian people. And for myselve, i have 
no idea how to deal with this. So, i''ll go "as is"...
> Newest latest clamav and
>spamassassin should work fine with sarge''s exim4, BTW.
>               cu andreas
>  
>
Good to hear.

Thanks for your infos..

-- 
Gerhard

On 2005-12-03 Gerhard Kroder <gerhard.kroder@t-online.de>
wrote:
> Andreas Metzler wrote:
> >On 2005-12-03 Gerhard Kroder <gerhard.kroder@t-online.de> wrote:
> >>me getting OT:
[...]
> >>How do YOU deal with this?
[...]
>> Current clamav for sarge is availble on volatile.
>> deb http://ftp2.de.debian.org/debian-volatile sarge/volatile main
 
> uuh, haven''t heard of "volatile" ''till now.
sounds interesting.
> >Once the dak
> >setup on backports.org is finished the packages will propagate to the
> >regular backports.org repository.)
> >
> Good to have alternatives, and i consider making use of them. But, as 
> side effect, we step out of the "stable" concept for productive 
> environments, don''t we? With no basic "in time" security
updates? I
> really appreciate people supplying backports, sideports and other 
> repositories, and i know they support this as far as possible. But this 
> probably less standardized as "regular security support".
[...]

Using volatile _should_ be just as good as running stable, see
<http://volatile.debian.net/>. The service is quite new, so it might be
too early to tell whether the promises are kept.

With backports.org the situation is approximately the same as with
running unstable. Breakage can happen (but is usually fixed quickly).
                cu andreas
-- 
The ''Galactic Cleaning'' policy undertaken by Emperor Zhark is
a personal
vision of the emperor''s, and its inclusion in this work does not
constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde

* Gerhard Kroder (gerhard.kroder@t-online.de) [051203
13:23]:
> patterns, too. So, won''t i be forced in time to change a stable
system
> (which is what i want in poduction environment) to a mixed system with 
> testing or sid?
Why? You can just use volatile.debian.net for this. :)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

* Gerhard Kroder (gerhard.kroder@t-online.de) [051203
16:36]:
> Good to have alternatives, and i consider making use of them. But, as 
> side effect, we step out of the "stable" concept for productive 
> environments, don''t we? With no basic "in time" security
updates? I
> really appreciate people supplying backports, sideports and other 
> repositories, and i know they support this as far as possible. But this 
> probably less standardized as "regular security support".
Well, volatile directly aims at "the updates the server admins need
which are more than just security bug fixes". And in terms of security
support, volatile was equal with security.d.o till now (and basically,
the volatile team did the stable security update as well, and forced
upstream to get cve ids etc ... :).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/

On Sat, Dec 03, 2005 at 03:35:41PM +0100, Hans-Juergen Beie
wrote:
> What is "stable"?
> - Bug-free software? That''s a dream.
> 
> - Bug-fixed software? OK (one bug fixed, get tow more for free ;)
> 
> - Debain/sarge? Hmm... that depends...
Debian stable is "the same software as it has been on the release
days, with security holes fixed." No functional updates.
> When I had to setup a (still small) production system for the first 
> time, I decided (after reading many of these Readmes, HowTotos, and 
> FAQs) to choose Exim4 on debian/stable (woody at that time) as a basis 
> and to provide the necessary environment by pinning (woody still sticked 
> to Exim3) or by using backports. This method was also suitable to get 
> recent versions of ClamAV and SA up and running, on so-called
"stable"
> debian flavours. Now with debian/sarge, this is quite similar.
With pinning, you quickly pull in low-level packages like libc6 or
perl from unstable/testing, leaving you with a bad compromise of old
(stable) and buggy (unstable) packages. Don''t do that. Use backports
whereever possible.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don''t trust Computers. They | Mailadresse
im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835