Re: How to package Nuxeo DM, a Java EE application, in Debian

[Stefane Fermigier <sf@nuxeo.com>]

On Feb 9, 2011, at 10:45 AM, Giovanni Mascellani wrote:

> Hi.
> 
> On 09/02/2011 10:06, Stefane Fermigier wrote:
>>> I'd say that this one of the main added value of a distribution:
>>> many different pieces of software harmonized together, under a
>>> consistent policy so that people that want to change something in
>>> the source code and recompile just have to do apt-get source, hack
>>> the code and dpkg-buildpackage.
>>> 
>>> Of course I'm not pretending that this is going to satisfy all the
>>> kind of users: it's just what Debian users are expecting, so it's
>>> what Debian is offering to its users.
>> 
>> Maybe I'm an exception, but I've been a Debian user since 1997 or
>> 1998 (not exclusively, but since that time I have always had from 1
>> to 30 Debian or Ubuntu servers to manage), and my home computer is an
>> Ubuntu.
>> 
>> I have NEVER used "apt-get source, hack[ed] the code and
>> dpkg-buildpackage." Not a single time.
>> 
>> Also, in the context of enterprise applications, you just don't want
>> to "apt-get source, hack the code and dpkg-buildpackage." You want to
>> run it through a massive amount of QA before putting it into
>> production.
>> 
>> Cf. http://qa.nuxeo.org/ for an example of what we do at Nuxeo.
> 
> Sorry, I may have missed some context: of course upstream developers
> don't use Debian package's sources, they work directly on the
> development copy they have.

I was not thinking about this case, but with my sysadmin hat.

Of course a developer won't use dpkg-buildpackage as his/her build tool !

> My "apt-get source, hack and dpkg-bp" was
> seen from a derivative developer or sysadmin that has to modify the way
> a software works on its own system or distribution.

As a sysadmin, I've never found the need to repackage a package.

If I need to configure a system, I will edit some files in /etc.

If I need to be more rigorous about it, I will but /etc under git control.

If I need to administer many servers this way, I will use tentakel or chef or puppet.

> 
>>> Probably other distributions make things differently because they
>>> are targeted to users with different needs. Other users could
>>> prefer the way maven works, so they will use maven to install their
>>> package.
>> 
>> Maven is a build tool, not an installation tool.
> 
> Just substitute the word "maven" with any installation tool you
> recommend for Nuxeo or whatever software we're talking about (including,
> for example, an APT repository different from the official Debian
> repositories).

For Debian / Ubuntu users, we actually recommend using our APT repo, indeed.

> The key here is that there are many software installation tool and many
> different repositories for each one of these different tools. The
> software that goes in Debian's main archive is allowed to be there only
> if it complied with Debian policy. There are many good reasons to think
> that the Debian policy is a good thing and probably you have others to
> think that other ways would be better: however, people using Debian
> repositories expect that repositories to be compliant with the Debian
> policy, and probably this is a reason because of they choose them. If
> you think that some pieces of software would benefit from being
> redistributed under a different policy, then build a different
> repository. Pretending that it should enter Debian violation its policy
> doesn't benefit anyone (and, as a matter of facts, is not possible,
> because it would be rejected).

I didn't "pretend" anything like this.

I'm insisting on the fact that:

1. there is room for interpretation in the so called "policies", for instance, that there "should only be one instance of tomcat" in the distribution.

2. sometimes the policies need to be changed in the face of reality. Otherwise, we end up like these poor monkeys:

http://freekvermeulen.blogspot.com/2008/08/monkey-story-experiment-involved-5.html

> 
>>> About the difficulty of having a Java application in Debian, I
>>> cannot agree more with Tony: packaging things in Debian is
>>> difficult, because it requires some added value that the packager
>>> must put into the package, and added value requires time.
>> 
>> This is not true, if the only thing needed was "some extra added
>> value" there would be
> 
> What is not true? The fact that packaging things in Debian is difficult
> or the fact that it's so because it requires some added value?

No, the fact that it *only* requires "some" added value.

You are requiring *much more*. You are requiring upstream developers to *completely change* their development process, dropping maven to use some non-existing tool, renouncing their QA process, etc.

> Of course, we could disagree on whether modifying a package to conform
> with Debian policy is an added value or not:

Modifying a package in a way that introduces significant variance (I'm not talking about tweaking the startup scripts to conform to the FHS, or adding an administrative panel, etc. I'm talking about changing a jar) *reduces* the value of a package, because it's not anymore the certified version (the one that has been through the extensive QA process).

> If you agree to have your software in Debian under these conditions,
> then we're happy to host it, of course. If you think that it's going to
> take too much time, I can't blame you.

It's not about "too much time". It's about asking upstream developers to *completely change* the way they are working, *completely reinventing* a whole family of build tools and processes that don't exist yet.

>> From my experience with working with both the Apache Foundation (I'm
>> with the incubating Apache Chemistry and Stanbol projects), and the
>> Eclipse Foundation (Eclipse Apogee, and a new project that willbe
>> announced today), I can guarantee you that their processes are as
>> annoying (or if you prefer, *rigourous* ;) that Debian's (wrt
>> licenses, copyright notices, etc.)
> 
> Not about embedded library copies, for example (as far as I can tell).
> I'm not saying that Apache or Eclipse are working bad, but they're are
> working differently in some ways. But Debian is made the Debian's way,
> not Apache's way.

Problem is, Apache and Eclipse and JBoss are the biggest open source Java projects collections, and by ignoring them you are definitively missing an opportunity of providing value to your users.

> 
>>> And, unfortunately, one of the core philosophies in Debian is that
>>> we're not trading quality for time or package number:

You're not just missing on "numbers", but on a *whole category* of valuable software (enterprise open source java software), for which not a single example (I have already asked on this and the ubuntu devel list if there was one) exists.

So this in not a quantitative trade-off, but really a qualitative one.

As a Debian / Ubuntu user, this time, I'm really pissed off that such packages are not available, and that I, or other members of my team, have to install and configure these packages by hand instead of using apt-get.

I'm also fed up with private apt repositories that only work with an obsolete version of Debian (or Ubuntu).

>>> if the
>>> available resources (that is, people that contribute to Debian) are
>>> scarce, then what we're giving up is quantity, not quality. Usually
>>> we're also able to offer quantity, but it's not our main focus.
>>> 
>>> BTW, in my little experience, I've already met at least two
>>> different pieces of software written in Java that were non free or
>>> even non redistributable because of licensing issues rising from
>>> putting JARs or copy and pasting code without checking if they were
>>> allowed to do so. I'm proud to say that, thanks to my work, now
>>> these pieces of software are really free in Debian: I'm sure this
>>> is not the only case, but it shows why all the thorough work that a
>>> Debian package needs it's useful.
>> 
>> Were these projects from "reputable" organization such as Apache or
>> Eclipse, or open source vendors concerned with the quality of their
>> products and minimizing the legal risk attached to their products ?
> 
> No, of course. But what does this change? From the point of view of me
> and many users, geogebra is much more important than JBoss, even it's
> not written by some big foundation.

What I was trying to say is that projects created by or through foundations or responsible companies tend to obey a certain legal and quality process, not that there are more important that other projects.

BTW, here's what geogebra's download page (http://www.geogebra.org/cms/en/download) says: "You are free to copy, distribute and transmit GeoGebra for non-commercial purposes".

Isn't this a flagrant violation of the DFSG (Item 6, "No Discrimination Against Fields of Endeavor") ?

  S.

-- 
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."