To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=55967
------- Additional comments from [EMAIL PROTECTED] Wed May 3 02:56:20 -0700 2006 ------- Well, this is getting a bit out of hand, but I'll bite. > It does not have to come with the OS, but it is always built for the > particular OS. It is better to require certain libraries/packages to be > installed, than to provide your own versions of them all. This is also known > as "DLL hell". Sorry, there is no way that we can build versions for the zillions of Linux distributions, two major and a number of minor versions of Windows and three major (with about a dozen of minor updates) Solaris versions (both x86 and sparc). But we don't let the customer stand in the rain. His copy of SO/OOo will work on any reasonable system. "DLL hell" is if you require your user to figure out all the dependencies. Oh, don't mind that he might have a need for a application which needs version x off library foo and another that needs y and the maintainer of foo made a little error in backward compatibility. As long as you keep your copy of libraries separate, there is only some wasted disk space, a resource which is not scarce nowadays. > OOo would save itself A LOT of work if it stopped trying to maintain the > 3rd-party chunks of the tree, and concentrated instead on the core OOo > software. > It would also reduce the distribution tarballs and cut the build times. You are seriously in error here. As I said before, streamlining 3rd party stuff is possible (and is done) for those who target certain distributions, but not for the general version. The general version can only take from the system which is there with absolute certainty (the precompiled version) or for the source version, which can be reasonably be expected from a developer system. An example is PAM. The effort of maintaining, say, a frozen version of icu in our tree is far below than that we would have to bear if we used the system version which might be not existant on an old system or might be broken (because to old) etc. And don't talk about the test matrix. Using our current approach we can be reasonably sure, that, if we test it on a number of new and old systems, it will work on any odd distribution. > By building *everything* from scratch, you are either duplicating (often > poorly) or even defeating the work of the system integrators, because the > superior streamlined versions are not built routinely and bit-rot occurs. Caolan and others did magnificient work to support the streamlined versions, but we simply need both. And don't tell to me about bit rot. Our old versions still work on new systems. When was the last time you tried something like this with - say - gnome? I don't claim there is not any 3rd party component which we could do better without. STLport is a good example. It was introduced when there was no way to do STL development with the sorry excuses of STLs which were shipped with the compilers. This certainly has changed and I wouldn't mind getting rid of STLport. This involves binary compatibility issues, and it involves getting things like hash_map, slist and rope working on Windows, which has an implementation which is not SGI derived. Some work but not impossible. But if someone does it, she/he has to do it for every platform which is supported, not just her/his favourite platform. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
