The Debian Java Package Team: Futility Defined

Maybe a year ago, maybe a bit longer, I was motivated to jump in and help get Maven 3 on Debian. Right? Maven 3 in Ubuntu, should be easy right? No, these people are smoking some strong, strong stuff. Evidently, they don’t like the Maven repository because it distributes binaries and distributing binaries is counter to the way linux distributions work.

You think this is crazy? Tough.

So, Central has 400,000 artifacts on it. 400,000 is not a small number, and the only way these Debian folks are going to keep up is if they figure out a way to map all of that into a system that fits into this idea of Linux source distribution. So, I dove in, sent some emails. The only way Maven 3 is going to get packaged is if all of the projects that Maven 3 depends on are packaged in the appropriate source…. zzzzzz. Translation: months and months of busy work just so that some Linux distro can be happy that everything is being compiled from source.

Whatever, back then I was motivated by the idea of “1. Install Ubuntu, 2. Run ‘apt-get install maven3’, 3. Make great victory” So I dove in and started to uncover a vast conspiracy of idiocy at the core of this distribution’s approach to Java libraries.

They have created a series of bash and Perl scripts (Perl, you ask, who brought that guy to the party.) These bash and Perl scripts perform a series of magical incantations that trick Maven into using a new repository. This repository has little to do with Central, it’s a special repository full of special POMs that have different versions. You’d have to be very strange to think this made any sense whatsoever. They even have a whole page dedicated to some idiotic interpretation of the Maven repository specification that shoehorns Maven into how Debian should work:

So, do something sensible and ignore all of this, it just creates problems for people who need to use Maven. Install it manually or just use the binary deb I’ve created. Don’t wait for these people because it will take them years to catch up with the rate at which the Maven community is moving.

7 thoughts on “The Debian Java Package Team: Futility Defined

  1. Its fine to have an opinion but listening is also an important skill. The discipline of building from source uncovers all kinds of problems and lets you do broad optimization that aren’t otherwise possible. Since Java focuses on a cross-platform bytecode this may seem less important but what if someone came up with a way to get 20% more performance out of java code on 64-bit AMD but it required you to rebuild JARs from source? If you require source as part of your packages and always build from source, this is trivial. If you only distribute binaries then you may have packages in your distribution that *no one* has the source for.

    How sure is the maven community that source for some of its binaries wasn’t lost because of bad backup policies? Do you really want those kinds of packages on your computer?

    Regarding Perl, if you think its so stupid why don’t you try running a short script in a shell loop 1000 times and time it? Now try it with Java. Maybe Java8 will get closer to that performance, probably not.

    Your hubris about the Maven community is touching and has some merit. One thing you should keep in mind, however, is that a Debian Java solution (if and when it ever succeeds in getting somewhere) will bring the entire universe of UNIX software with it. That means you’ll be able to do things like “apt-get install my-awesome-cluster-solution” and *poof* you get a Java, Memcached, CouchDB, Erlang, 0MQ and whatever tool chain as easy as 1, 2, 3.

    Its easy to call people stupid but its a lot more helpful if you actually look at their motivations and try to understand their merits. In this case, I don’t think Debian is just “smoking strong stuff”. There are reasons for what they are trying to do even if they seem counter-productive.

  2. WTF is up with all of this holier than thou open source nobility? The fact is that the Debian Java packaging team disagrees with the fundamental definition of how a Maven repository works. Instead of figuring out a better way, what did they do? They’ve gone and tried to redefine it, and they ship incompatible crap that confuses and misleads people.

    I don’t disagree that “there are reasons for what they are trying to do”, what I disagree with is the wasted effort. “If and when it ever succeeds” – good luck waiting around for that.

  3. Oh well, this is why you shoudn’t drink before ranting.

    PS: That “incompatible crap” is the only thing Debian is legally allowed to distribute.

  4. So we’re coming from these points (I’ll just try this once and not followup if you try to reference any “better than you” crap):

    * All source should be available for the user to modify and rebuild. (c.f. DFSG)
    * We want one single source version of a library so that we only have to patch one when a security issue pops up. If possible. For a transition time it’s ok to have multiple ones, also if the API changed severely it might make sense to package two. (But more than two is pretty uncommon. Certainly not twelve.)
    * The Debian build infrastructure is not allowed to download random bits of binaries from the internet.

    That’s the thing I parse out of “Problems with upstream’s repository (central)” with Debian background. If Maven makes it hard to satisfy the three above (NB: Almost all other programming languages except maybe Ruby make it more or less easy to satisfy exactly that workflow. And we ship a truckload of them.), then they need a way to work around it. Now of course you could try and understand what kind of changes are needed in Maven to accomodate that. And maybe implement them. The Java team tried. Maybe their approach doesn’t fit, I cannot judge that, but there’s a certain philosophy we agreed on and on which we won’t compromise (DFSG is one; “don’t let our project machines be compromised” is another one sanely imposed by our admins; “as few packages to patch for a vulnerability” is the last one imposed by our great security team).

    Yes, there are conflicting interests between the user view and the developer view. We’re not doing that to piss you off. We’re doing it to provide exactly that value to tinker with components to our users. And of course you’re free not to use our work. You’re of course entitled to your opinion, but please use it to influence the work of the team on the grounds of the three points above as given. I understand that they might be hard to accept when coming from another background, but they explain why the Java team needed a workaround for Maven, I think.

    Maybe it helps you understanding Debian, maybe not. If you have specific questions about our culture, just ask them in a calm way.

  5. Right, I didn’t drink, but if you’d like I can rewrite another version of the post after drinking, I’d probably then tell you what I really think.

    So, by your logic, Debian isn’t allowed to ship binaries (absolutely I get that), so the best answer is to ship a freakishly customized version of Maven that reinterprets the fundamental notions of how a binary works accompanied by a whole boatload of crazy scripts that rewrite POMs (and POM dependencies). This makes no sense, how about defining this effort as outside the scope of the Debian distribution?

  6. Here’s a “calm” reply. Your three assumption are evidence that you are shipping a wholly incompatible piece of software that you are calling “Maven”.

    * All source should be available for the user to modify and rebuild <– That's fine, I agree.

    * We want one single source version of a libr…. <– This is pure nonsense. Why is it the Debian's teams prerogative to screw with POM versions?

    * The Debian build infrastructure is not allowed… <– Agreed, but we're not talking about the Debian build infrastructure, we're talking about end-users.

    Do whatever you want to support internal Debian development, but please stop shipping an incompatible version of Maven. I can't tell you how many times I've had to walk people back from issues with repackaged Debian JARs.

Comments are closed.