static libraries, dev packages and libc

[Brian May <bam@debian.org>]

Hello,

I bring two separate issues here, please don't get them confused ;-).

I have ideas on how these issues could be resolved, but want say
anything just yet unless somebody can confirm that they really are
problems...

ISSUE 1

Is it ok to compile a static library of a unstable system, and then
move the static library to unstable to compile a binary?

This is a bad idea for shared libraries because of the different
versions of libc. What about static libraries though?

The reason I ask is because apt-get 0.5.0 wants to upgrade
libhsync-dev, which contains a static library, but not libc, so I was
wondering if it should depend on libc or not.

My guess is that it is OK, since libc isn't linked until the binary is
built.  However, you could argue that it uses the libc include files
from unstable. Is this a problem?


ISSUE 2

(you could argue this isn't really a problem, but I think it
deserves consideration).

I locally compiled certain libraries here for stable, eg libsasl, and
installed them locally. (A similar situation exists for libldap2-dev).

However, apt-get wants to upgrade libsasl-dev (and not libsasl7), to
the Debian version. This is because:

1. libsasl-dev can be installed without upgrading libc.
2. the version number libsasl7 installed is the same.
3. apt-get realizes that the package is different (I think it must compare
the md5sum or something).

So, I could have the unexpected situation where the static library
doesn't match the shared library.

I can't think of any real problem this would cause, just unexpected.
If however, issue 1 is a problem, then issue 2 may become significant
(as the static library was compiled on an unstable system).
-- 
Brian May <bam@debian.org>