Stefane Fermigier <s...@nuxeo.com> writes: > On Feb 10, 2011, at 7:50 PM, Russ Allbery wrote:
>> For those of us who have been doing this sort of thing for a while, >> this argument sounds very familiar. I've heard this argument applied >> to C libraries, Perl modules, Python modules, and most recently Ruby >> modules. It always sounds persuasive when presented from a stability >> perspective. It has always proven to be completely wrong in the long >> run. > Please develop, unless you want me to believe you only based on your > reputation, which I won't since I don't know you. You're advocating for a (very significant) change in Debian Policy, and I think the burden of proof is on showing why Java libraries should be treated differently than every other library in Debian. They pose the same challenges for security support, for ensuring rebuildability of software, and for keeping the whole distribution moving forward in an integrated fashion, and therefore the same issues apply. So, I think you have the burden of proof reveresed. I think you have to convince Debian that Java needs to be a weird special case, rather than asking me to convince you that Debian's policy for every other language should also apply to Java. You can look at the infrastructure and handling of libraries in every other language in Debian, and observe that they all follow the system that we're asking Java libraries to follow as well. Java isn't being singled out here. Historically, every one of those languages have presented the same argument that you're presenting. For example, including convenience copies of C libraries in other applications (zlib was a major offender), or slightly modified versions of those libraries, or requiring specific versions, used to be widespread. Application developers argued long and hard that this was required for stability and that they would handle security updates. It wasn't required for stability, and they didn't handle security updates properly. Debian, and just about every other Linux distribution, put our collective feet down and said "no, we're not going to do things that way." And as a result, the library handling for C applications is now far, far more sane, reasonable, and maintainable than we could have ever anticipated back when this started. Getting there is a lot of really hard work, but I'm convinced that the same thing will apply in the long run to Java, to Ruby, and to every other language that's fighting these same issues around stable ABIs and shared code across multiple projects. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tygbk150....@windlord.stanford.edu
