> > Any other incompatibility lies in libraries, but we have library
> > versioning. There is nothing wrong with newer libs breaking
> > compatibility so long as they have a different soname. Vendors just
> > need to ship compat libs and ISV's need to make sure they request the
> > right lib and don't touch internals.
> >
>
> Part of the problem is knowing which things to request. I've
> envisioned a database that has the matrix of tests and packages so that
> people like ISV's and system integrators will be able to look
> up what has been tested and passed. I think that this database
> is the crucial portion of the new development.
library versioning is precisely the tool which is designed to
keep stuff from breaking. Things break when library authors
break compatibility *without* going to next major version
or when app writers blidly use latest-n-greatest lib version
*without* checking that major version # of it matches
what they were writing against.
Matrix would be a workaround to these problems,
not a proper fix.
OTOH, it is true that large projects like e.g. KDE
have enough other problems and do not pay much attention
on ability of latest KDE3 to coexist with legacy KDE2
on the same box. They drop _unversioned_ .so files into
/usr/lib. /usr/include/kde has no version # too
(unless fixed by configure option or by hand after
install).
Probably KDE2 is history and not worth bothering about
for core KDE team, but app writers might disagree I think.
This happens with some other large projects, too.
--
vda
___________________________________________________
.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
