[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dependence on specific versions



Stefane Fermigier <sf@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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>


Reply to: