Re: on bootstrapping ports (was: Re: Bits from the Release Team (Jessie freeze info))
On Monday, October 28, 2013 12:15:09 PM Emmanuel Bourg wrote:
> Le 27/10/2013 16:30, Daniel Schepler a écrit :
> > (To be honest, the
> > Java packages are such a tangled mess that I've given up on trying to
> > bootstrap that part of the archive for now -- and many of those do get
> > pulled into the minimal set of ca. 1473 source packages I get with my
> > criteria.)
> Hi Daniel, could you elaborate on the tangled mess of the Java packages?
> As someone who cares about the Java packages in general I'd be
> interested in hearing what could be improved.
(Let's take any more detailed discussions on this off debian-devel and leave it
just on debian-java.)
The first task would be to bootstrap gcj and then openjdk (and the latter's
binary dependencies on libatk-wrapper-java-jni, ca-certificates-java, tzdata-
java). Then I have to bootstrap ant, which is made difficult by the fact that
there are so many Build-Depends needed before it's possible to build a full
version of ant-optional. In the past I've done that by first building just ant
from that package, and then whenever one of the indirect Build-Depends of ant-
optional has a Build-Depends on ant-optional itself, I build a throwaway
version of ant-optional against whatever I have available at that point. But
now, with libgnumail-java having a Build-Depends on bnd which Build-Depends on
some packages from eclipse, I don't really have any idea how to handle that,
other than to drop the call to bnd and cross my fingers hoping nothing needs
whatever the bnd call adds to that package.
Mixed in with that, I also have to bootstrap maven-repo-helper, and for a few
packages that I need before I'm able to do that, I do the ugly thing of just
taking the metadata files from existing packages and installing them by hand
into bootstrapped packages. Then, the next major hurdle is that many packages
that are part of the Maven build system or its binary dependencies have Build-
Depends on maven-debian-helper themselves. A while ago I figured out a way to
bootstrap this using maven-ant-helper, but that's a long drawn-out process
involving probably hundreds of packages. And I'm not sure that my process
will still work, as there are even more packages that have switched to using
maven-debian-helper to build in the meantime, including libjaxen-java which
has always been a headache because of its circular Build-Depends with dom4j,
libjdom1-java, xom. (Also, maven-ant-helper itself isn't necessarily that
easy to bootstrap, as it Build-Depends on ant-contrib, which Build-Depends on
ivy, which Build-Depends on libcommons-vfs-java, which needs maven-debian-
helper.) And yes, maven-debian-helper is part of that set of ca. 1473 source
packages, for example via the chain x11proto-core -> fop -> xmlgraphics-
commons -> mockito -> objenesis -> maven-debian-helper.
Anyway, that's just an overview of the main issues I face with a bootstrap of
the Java packages. If you want, I could restart my bootstrap process and let
you know in more detail what Build-Depends cycles I run into (and solutions
where I've been able to find them in past iterations).
Obviously, though, very little of this will be relevant for the case of
bootstrapping a new port, using the existing Architecture: all packages.
--
Daniel Schepler
Reply to: