Re: Frustration with trying to build Debian packages from Maven-based sources
Emmanuel Bourg <ebourg@apache.org> writes:
> Thank you for taking the time to look into jdeb.
> My reasoning is the following:
> - The binary package must be built from the source
> - This is currently done with a fairly sophisticated make file
> - We are free to use the build tools we want (is that correct?)
> - So Maven or Ant could be used instead
> - Java developers let jdeb build their packages (with Ant or Maven)
> Would that work? You still have a proper source package, but the hard
> work is delegated to Maven/Ant.
The serious problem here is that Debian relies on packages sharing the
same underlying toolset so that we can make global changes for new
versions of Policy. It's not strictly *required* that everyone use the
same tools (although it's very, very close to required that one use
dpkg-deb), but it's definitely helpful, and I'm not aware of a large
packaging team that doesn't base their work primarily (possibly through
indirections like CDBS) on debhelper. Those who choose not to use that
infrastructure are generally some of the most engaged project members, who
are choosing to do something different because they have a lot of
low-level understanding of packaging and are willing to keep adopting
their tools to different purposes. And usually they're maintaining
relatively simple packages.
Based on the documentation of jdeb, it appears to be a pure NIH solution
that reinvents every wheel from the ground up (at least, that's how I read
"it does not require additional native tools installed". That means it's
effectively a reimplementation of not only debhelper in Java but also all
of the dpkg tools, which would have to be separately maintained for
further changes to the Debian packaging expectations. That's really
unappealing, particularly given that the packaging team is already short
on resources.
> In my opinion the main "selling point" of jdeb is to let Java developers
> take care of the packaging of their own applications or libraries with a
> tool close to their current tool chain (Maven or Ant). They don't have
> to learn all the subtleties of the Debian packaging tools. That's an
> opportunity to distribute the load of packaging Java softwares for
> Debian over a broad range of developers instead of relying on a small
> set of experts.
I'm all in favor of the idea of building reusable tools and trying to make
packaging as simple as possible. This is the idea behind other tools,
such as dh-make-perl, which have been quite successful. You can indeed
get huge mileage from that approach, to the point where packaging a
"typical" JAR would be entirely turnkey the way that it basically is for a
"typical" Perl module now. But all of those tools have a normal Debian
package structure as their output format, and then let the normal Debian
tools do their work, and that's vitally important. That allows the normal
Debian techniques and tools to keep the package up to date with changes in
packaging standards, and for fixes to be applied to those packages in the
same way that they are to any other Debian package without the *Debian*
teams having to be aware of or fix some Java-specific packaging system.
In other words, the goals are great, but what jdeb is doing is a little
like building Red Hat packages without using spec files or (perhaps closer
to home) replacing Maven with a system that builds Java JAR files using
Perl. Even if that Perl script works really well right now, I doubt that
would be a solution that would make most Java developers very comfortable.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: