On Tue, 2006-12-26 at 18:13 +0100, Leon Rosenberg wrote: > > Except that you'd have to download the dependant stuff in the > appropriate version and not just latest from head or release.
Sure so you could be downloading and using a version of a library with bugs that have been fixed. Why live in the past with binaries, it's pretty much goes against the entire concept of Open Source. Because most people never touch the source, it never get's compiled. They just work with binaries. So are they really running open source software or just free binaries? Also don't think Tomcat download targets in ant don't break due to versions. In between minor releases, that stuff only gets bumped if it's needed or caught. Most times it will keep being compiled against an older version even if newer ones exist. No reason for that other than laziness, or over worked devs not to concerned with the versions of all the deps. > Take the binary version (which isn't binary after all:-) ) and simply use it > :-) Part of that is the difference from running a binary distro, or a compile from source distro. Also your suggestion means I have no way to run a 1.5 bytecode version of Tomcat. Or 1.6 bytecode. Since the upstream binary is compiled as 1.4 bytecode. Despite needing a 1.4 compat lib to actually run properly under a 1.4 jre. > Maybe that most of us are java aware, but less c aware. Probably > people who are heavily working with the c-stuff don't use c packages > either :-) That's just it, where are the C packages? Quite many don't release C binaries do to all the differences. Like Apache :) Java should have adhered to this as more Open Source Java apps came into existence. However build systems have suffered tremendously, and there was no preparation for the current state of Java. Now that 1.6 is released, what bytecode will the next binary version of Tomcat be? 1.5? 1.4? 1.6? You will start to see this becomes a mess and most control is taken from you. And considering 1.7 is likely about a year away. :) Some upstreams have started releasing their binaries in multiple versions. That is hardly ideal for packagers, and as bugs pop up, should be interesting. > Again, why? If you want the latest commons for your webapp, feel free > to drop it in your webapp. Your webapp can't access libs used by > tomcat anyway. If you want to update the one tomcat uses, replace the > one in server libs. If it doesn't work, recompile wouldn't probably > work as well. But that doesn't effect the code Tomcat was compiled against. So bugs could be persisting into other areas of Tomcat without ability to address. Short of compiling from source against the newer versions of dependencies. Considering again what started this tread. That allot of dependencies are needed at compile time, but not runtime. So after compile, no way to replace, update, etc. > Nothing against gentoo, but sofar everyone I know of, who was using > gentoo is now un (k)ubuntu. Nothing wrong with that. To each their own. But could say something about your circle. Most I know that setup Ubuntu for newbs to learn Linux with. Move them onto Gentoo due to lack of flexibility when one is downloading and running pre-built binaries. I have run into issues on quite many version of Linux, where a binary lacked a feature I wanted to use. -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
