Christian Weisgerber wrote:
We need some sort of policy how to deal with software written in
Java. We have a number of ports that are basically just wrappers
that install pre-compiled Java byte code. Additional ports in this
style have been proposed. Actual Java source may or may not be
available, but it is certainly not used by the ports in question.
The source code is available for all of the programs AFAIK. If anybody
thinks I have put anything into the ports tree for which source is not
available, let him quote chapter and verse.
The source for the JDK - which you need to compile any of the others -
does require manual downloading because of a click-wrap license.
That is not the issue. The source for all of them is available. So is
the source for redhat-* and freebsd-libs, but we've been shipping those
as binary blobs for years. There are ~30 RPMs in redhat/base alone,
including X libraries. You're going to recompile all of that on
every bulk build of ports?
Some people--Marc Balmer has been very outspoken--dislike this
approach, because we are just wrapping other people's binaries.
Instead, ports should fetch the source and newly compile the code.
The counter argument from the Java people is that Java byte code
is machine-independent, compiling it afresh will just produce the
very same binaries, adding build time for no gain.
That's the same argument as using PDFs in /books. First, if the book is
only available in PDF, should we refuse to install it because it might
have malicious code that would trigger a buffer overrun in xpdf or one
of the libraries? Second, if a book is available in PDF but also in
LaTex, should we insist that somebody install all of LaTex just to build
it? And further, should the ports build machines have to do this on
every platform (even vax :-)), or, should there be a means in the
ports mechanism to say that "the package that this builds works on any
platform" - this would apply to building PDF and building Java, among
others.
And it also applies to the linux-libs and freebsd-libs, etc.
If you are going to be consistent and say "build everything", you are
going to be setting up cross-compilation and building all the linux
libraries and the freebsd libraries every time you do a full ports build.
An additional
complication is that passing around binary archives seems well-accepted
in the Java scene,
It is, when they are from a recognized site like Apache or Eclipse or Sun.
Just as people use packages from an OpenBSD mirror.
And we use linux packages from redhat, PDF packages from Sun, O'Reilly,
and others.
posing problems of obtaining the actual source
code and exploding dependency requirements.
The dependency requirements are the real issue. The source for the IDEs
is huge; source for one of the other ports (glassfish, IIRC, a J2EE
server) is larger than that of OpenBSD kernel+user together.
How are we going to deal with this?
Some preliminary discussion at the last hackathon produced the
opinion that even Java ports should be built from source by all
means. However, that discussion didn't include any of our porters
who are interested in Java... The source requirement may render
various ports impossible or impracticably difficult. We'll need to
decide whether we put our foot down here.
Put a SECURITY file in pkg/ for anything that hasn't been completely
built by us, whether it's Java, PDF, a port that installs linux or
freebsd libraries, or even a port that installs a wireless card blob.
And, make sure there is a link where to get the source for those who
have time to spend downloading and building every prerequisite.
Ian
P.S. Good time to re-read Ken's paper Reflections on Trusting
Trust (online at http://www.acm.org/classics/sep95/), before you decide
where to put your foot down.
