Source tarballs

[Tom Marble]

Andreas Sterbenz wrote:
> Xiomara Jayasena wrote:
>>
>> We really didn't see the need, hence we decided to get rid of them. 
>> It seems anyone working in JDK 7 may need to become familiar with hg
>> -- that said I appreciate your input.  Here at Sun we will no longer
>> be using the tarred source and expect engineers to do clones and that
>> is the same expectation for developers outside of Sun.   If many
>> people think this is crucial then the decision can be re-evaluated.
> 
> It is still possible to get source tarballs - by going to
> http://hg.openjdk.java.net/ . Just click on the zip/gz/bz2 link next to
> the desired repository to get the tip (e.g.
> http://hg.openjdk.java.net/jdk7/jdk7/archive/tip.tar.bz2) or navigate to
> the changeset or tag you like and follow the download link (e.g.
> http://hg.openjdk.java.net/jdk7/jdk7/rev/0a5c5386a678).
> 
> The only thing it doesn't do is understand forests, so you have to
> download the source for each of the seven repositories in the forest
> separately (/if/ you really want them all).

I'd like to ask if we (Sun) can reconsider publishing one (1)
source tarball for promoted builds.

This question has come up in the past in the context of many
Free Software distro build daemons which proscribe live Internet
access during binary builds.  Usually there is a "source package"
which is uploaded to the build daemon which specifies any build
time dependencies (e.g. specific compilers, header file packages)
and includes the upstream tarball(s).

This question came up again, today, on IRC in the context of
building OpenJDK for stable distros.  Developers stated that it
is very desirable for non-root users to be able to build OpenJDK
on stable distros by making only one simple request to their
system administrator for a list of build dependency packages.
While the user may have Internet access she cannot specify
packages which were not part of the stable release.

Without an OpenJDK upstream tarball this means that the typical
way of getting the OpenJDK source is with "hg fclone" [0].
Which means that one would need Mercurial [1] with the Forest Extension [2]
(and Mercurial needs python 2.4).  This is complicated by the
fact that the Forest Extension (currently, unversioned) is only
supported on Mercurial  0.9.3, 0.9.4, and 0.9.5.

If we take such a stable distribution, Debian etch [3] for example, then
we find the following:
  python
    2.4.4 http://packages.debian.org/etch/python/python
    2.5   http://packages.debian.org/etch/python/python2.5
  hg
    0.9.1 http://packages.debian.org/etch/mercurial
    0.9.5 http://packages.debian.org/etch-backports/mercurial  BACKPORT
  forest
    (no version number) requires Mercurial 0.9.3, 0.9.4, or 0.9.5.

This looks promising, except I learned that the "backports"
repository is not considered part of the primary distribution and
thus could not be used as a build dependency.  The other problem is
that getting forest.py configured for the system "hg" (i.e. not
requiring every user to fix their ~/.hgrc) would require a new
package (i.e. mercurial-forest) which is also not possible because
such a package did not exist (and still does not) at the time
the stable distribution was frozen.

In distributions where hg 0.9.5 is available then there is solution
(albeit less desirable) to have the user add forest.py to ~/bin
and the path to ~/.hgrc (or equivalent in the build directory).

Another possible solution, along the lines of what Andreas suggested,
would be to grab the 7 tarballs from upstream and then combine them.
If I understand this correctly, however, it would require scripting
(or publishing) for each promoted build tag a set of changesets
for each subordinate repository (e.g. b24 [4]).

Compared to this complexity of these solutions if we simply published
one tarball then supporting hg 0.9.5 and the forest extension would
not be a build requirement.

Please let me know what you think (esp. if I have characterized
the solutions accurately).

Regards,

--Tom

[0] http://weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html
[1] http://www.selenic.com/mercurial/wiki/
[2] http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension
[3] http://www.debian.org/releases/etch/
[4] http://hg.openjdk.java.net/jdk7/jdk7/log/cfeea66a3fa8