RE: [libxml++] static libio

[Murray Cumming Comneon com]

> > I think what you need is API stability, and that is on the way. If not,=
 why
> > else would 2 packages need different versions of libxml++?
>
> Note that it's not a theorical question but a practical one.
> Should I wait for libxml++ 0.28 ?
> Right now we have 0.23 and it's not easy to compile today's app with it.

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.

> > 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 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.

Murray Cumming
www.murrayc.com
murrayc usa net