Laszlo Peter wrote:
Hi Rod,

Thanks for the detailed response.

Of course I agree that it's better to avoid the problem by
carefully controlling public interface changes. However more
and more software in Solaris comes from external sources ...

So we can't break the interfaces we'd shipped but we can't
not update either.
My favourite example is libxml2 ....

Understood.  My posting was more an intent to describe where are
focus has been over the course of developing Solaris.  As the
environment around us changes, so our focus will have to change.

So I still think that well controlled and documented duplication
is this the only way in these cases.  I'm not taking about
duplicating every single open source library, only the ones
we are not allowed to break and only when the community
maintainer breaks it and refuses to fix it.

How to do this, or whether it's possible to do it correctly is
another question.  I don't know enough about this topic to make
any suggestions.

Right, but it's not simple.  Building app1 against one set of dependencies,
and app2 against a different (incompatible) set, isn't rocket science.

Building dll1 against one set of dependencies, and dll2 against a different
set, and determining what should occur when dll1 and dll2 meet in the same
application gets trickier.  Knowing what to do with dll3 who makes reference
to a function that exists in both sets of dependencies, when dll3 wasn't
explicit about what set it required, is even more fun.

I still maintain that when you offer multiple versions of a dependency,
you are asking consumers to make a choice.  Customers don't always want to
make these types choices.

Plus, by offering this type of technology you may be encouraging incompatible
change, thus making customers have to make more choices.

Anyway, there are lots of threads regarding compatibilities going around at
present, so let's not start another :-)

We have no mechanism at present, and none that I know of in the pipeline.

--

Rod.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Reply via email to