Re: Extra packages in the next point release?

[James Henstridge <james daa com au>]

On 19 Jul 2001, Dick Porter wrote:

> On 17 Jul 2001 13:45:41 -0400, Daniel Veillard wrote:
> > On Tue, Jul 17, 2001 at 12:25:12PM -0500, Chema Celorio wrote:
> > > On 17 Jul 2001 13:00:52 -0400, Daniel Veillard wrote:
> > > ..
> > > >   So I ask, what about adding libxml2 now (adding, not replacing libxml1).
> > >
> > > I think it is a good idea. Starting to port stuff to libxml2 will also
> > > not be a problem cause you can link with both right ? If this is the
> >
> >   No you can't they export the same symbols,
>
> But you can set up configure.in and the code to work with either with
> minimal pain.

That is not the issue really.  If only applications used libxml, then
there would be nothing stopping us from switching over to libxml2, as the
migration could be done at whatever pace is best for the app maintainers
(being able to install both libxml's in the same prefix would probably be
required for this as well -- libxml1 would need to stay around for
binary/source compat).

The problems come with libraries that use libxml.  A copy of gnome-print
(or libglade, bonobo, etc) compiled with libxml2 is not compatible with
one compiled with libxml1.  To an app that doesn't use libxml itself,
there is probably no difference, but if the app also uses libxml, then
things will be problematic if there is version skew between what the
library uses and what the app uses.

The way around this would be to compile two versions of each library that
uses libxml -- one with libxml1 and the other with libxml2.  These two
libraries will have to have different names (not just differing in the
version number), as we need to support building apps with both libxml
versions.  So we might have libgnomeprint.so and libgnomeprint-xml2.so.

After the libraries have been updated to build libxml2 versions, apps
could switch over to libxml2 (they would need to make sure they linked
with the correct versions of other libraries though).

This may seem tedious, but it is required to keep platform compatibility.
As a side effect, it brings a number of extra libraries into the platform,
and increases the amount of testing needed for making releases of the
libraries (testing both versions).

The easy way around this is to break source and binary compatibility and
switch over completely.  But then this starts to sound a lot more like
gnome 2.0 than 1.4.1 ...

James.


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers