On Mon, Mar 15, 2010 at 03:55:15PM +0100, Max Horn wrote:
> 
> This is certainly not a huge issue, but I still found it quite disturbing. Do 
> I really need db44(-aes), db47(-aes) and db48(-aes) all at the same time? 
> Hrmm... So I looked a bit, and discovered the following:
>   
> * svn, libaprutil.0-* (and python26) depend on db47(-aes)
>   and svn depends on libapr.0-dev
>   
> * cyrus-sasl2 and openldap24 depend db48-aes
>   and svn depends on cyrus-sasl2-dev and openldap24
[...]
> * python25 depends on db44(-aes)
>   and unfortunately xchat depends on python25
> 
> I'll look into changing xchat to allow newer python, thus hopefully taking 
> care of the db44 part.
> 
> But maybe we can also change our python25 to use db44? Can we change [...] 
> python26 to use db48 instead of db47?

python25.info DescPackaging:Cannot use db47 (or higher)
python26.info:DescPackaging:Cannot use higher than db47

There are interface changes of some sort. I don't think anyone's
looked more deeply than trying and failing to compile.

> Can we change svn, libaprutil.0, [...] to use db48 instead of db47?

I talked to thesin a week or two ago, he said he was working on a new
round of libaprutil and relates packages. I assume svn simlpy inherits
whatever apr has.

> I am not sure whether this would cause binary compatibility issues; but if it 
> is sanely possible, it would be preferable to use a single db4x version for 
> all these packages, wouldn't it?

Two-level namespace *should* encapsulate things within each lib, but
if one lib passes a struct or database to another, there could be
problems. With the loss of .la data (due to deleting those files or
installing dpkg-base-files) there is less propagation of library
dependencies that are not actually used, so it's possible that (for
example) svn doesn't need db4* at all itself.

dan

-- 
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fink-devel mailing list
[email protected]
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to