RE: [libxml++] static libio

[Christophe Barbé <christophe cattlegrid net>]

Le sam 06/12/2003 à 15:45, Murray Cumming Comneon com a écrit :
> Yes, you should wait for API stability instead of confusing everyone who
> tries to install libxml++. It will happen very soon now.
> 
> In the meantime, your problems seems to be that the libxml++ in debian seems
> old. Bug the debian mantainer about that. I can't believe that they would
> hold back a libxml++ version just because another application depends on it.
> An unstable API is an unstable API, and no application should expect to hold
> back all other applications just because they are too lazy to track the API
> changes.

Aren't you contradicting yourself here? You said wait for the stable api
and than said that the libxml++ in debian is too old?

> > > This should be completely analogous to libraries such as gtk+. You do n=
> ot
> > > need different versions of gtk+ 2.2 installed, apart from the unpleasan=
> t
> > > stuff with the different versions of gcc, of course.
> >
> > I am not sure it's a good example. On my system, I have both gtk+ v1 and
> gtk+ v2 installed.
> 
> Yes. You have gtk+ 1.2 and gtk+ 2.2. These are separate,
> parallel-installable APIs. But you do not have
> Both gtk+ 2.2.1 and gtk+ 2.2.2, because the API/ABI is stable, so replacing
> gtk+ 2.2.1 with gtk+ 2.2.2 does not break anything.

I could give you the example of libgal but I am not sure it would
convinced you. 

> I guess that debian even had debs of the unstable gtk+ 2.0.x and 2.1.x
> phases, and maybe now gtk+ 2.3.x, but no applications would stop the newer
> versions of gtk+ from getting into debian.
> 
> It's a very bad idea.
> 
> [snip]
> > What are the reasons to not statically link libio in libxml++?
> > Or at least make it install in a libxml++ path instead of directly in
> > /usr/lib/ (like /usr/lib/libxml++${major}/ as common practice).
> 
> So far I have no idea why you are mentioning libio specifically.

Ok I will try to explain it another way. From your source I generate
three debs:
	libxml++13_0.27.0-1_powerpc.deb
	libxml++-dev_0.27.0-1_powerpc.deb
	libxml++-doc_0.27.0-1_all.deb
The libxml++13 contains:

$ dpkg-deb -c libxml++13_0.27.0-1_powerpc.deb 
drwxr-xr-x root/root         0 2003-12-06 11:06:21 ./
drwxr-xr-x root/root         0 2003-12-06 11:06:17 ./usr/
drwxr-xr-x root/root         0 2003-12-06 11:06:19 ./usr/lib/
-rw-r--r-- root/root     15564 2003-12-06 11:06:19 ./usr/lib/libio.so.0.0.0
-rw-r--r-- root/root     93736 2003-12-06 11:06:19 ./usr/lib/libxml++-0.1.so.13.0.0
drwxr-xr-x root/root         0 2003-12-06 11:06:17 ./usr/share/
drwxr-xr-x root/root         0 2003-12-06 11:06:17 ./usr/share/doc/
drwxr-xr-x root/root         0 2003-12-06 11:06:20 ./usr/share/doc/libxml++13/
-rw-r--r-- root/root     11299 2003-10-28 12:23:34 ./usr/share/doc/libxml++13/changelog.gz
-rw-r--r-- root/root       354 2003-12-06 11:02:44 ./usr/share/doc/libxml++13/copyright
-rw-r--r-- root/root      1661 2003-12-06 11:02:44 ./usr/share/doc/libxml++13/changelog.Debian.gz
lrwxrwxrwx root/root         0 2003-12-06 11:06:19 ./usr/lib/libio.so.0 -> libio.so.0.0.0
lrwxrwxrwx root/root         0 2003-12-06 11:06:19 ./usr/lib/libxml++-0.1.so.13 -> libxml++-0.1.so.13.0.0

If you look at the content you will see that only /usr/lib/libio.so.0*
does not mention libxml++ and the soname 13. So it will prevent the
installation of libxml++14 along libxml++13 (because both are likely to
contain /usr/lib/libio.so.0.0.0). 
Looking at the content of libio headers, I believe it's libxml++
specific so moving libio in /usr/lib/libxml++/ would make sense.
This also makes sense from the namespace polution point of view (not the
C++ namespace, the /usr/include/ namespace).

Now another solution, that seems to be you favorite, would be to create
a binary package called libxml++ (without the soname) and force all
packages using it to be rebuilt.
This solution is fine for stable API but not for libxml++ today. 

Christophe 


> Murray Cumming
> www.murrayc.com
murrayc usa net
-- 
Christophe Barbe <christophe barbe ufies org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E