Re: java: switch to icedtea-8 as default JDK

["Gábor Boskovits" <boskovits@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]

Hello!

I have a few idea, which could be done in parallel with this.

I don't know if they worth considering, but here they are anyways.

We could split the bootsrap part out of java.scm, to something like
java-bootstrap.scm.
We should stick here to specify versions used and not allow defaults.
We could name packages which will be used by the final consumer like
foo-bootstrap.
The have a file like java-checkpoint.scm only with definitions like (define
idectea8 icedtea8-bootstrap).
This would make the checkpoints we discussed on  the Reproducible Build
Summit more visible, and explicitly declare which packages are the real
base of java. We do not allow using java-bootstrap from anywhere else, but
from the checkpoint.

Another thing we could is have something like java-defaults.scm with
definitions like (define icedtea icedtea8). This would make default
settings more visible, and might server as the basis of an alternatives
like system.

Later these steps could be done on other languages, making the trust base
more explicit, showing where we need bootstrapping done, and which pacakges
should be bootstrapped.

For organizational purposes whe might create a directory for defaults,
checkpoints and bootstraps.

Also with java9 coming we should be prepared to do another iteration on
this, and a cleaner sturcture might make that easier.


2017-11-29 8:12 GMT+01:00 Chris Marusich <cmmarusich@gmail.com>:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
> > Gábor Boskovits <boskovits@gmail.com> writes:
> >
> >> Hello!
> >>
> >> I just run a quick grep to see which files might be interesting.
> >>
> >> We use ant-build-system in:
> >> axoloti.scm *
> >> bioinformatics.scm *
> >> compression.scm *
> >> icu4c.scm
> >> java.scm *
> >> libusb.scm *
> >> music.scm *
> >> textutlis.scm
> >> uml.scm *
> >> version-control.scm *
> >> web.scm *
> >> xml.scm
> >>
> >> Only the ant-build system uses icedtea among build systems.
> >>
> >> Icedtea is explicitly metioned in the ones maked with *, and:
> >> kodi.scm
> >> math.scm
> >> ruby.scm
> >>
> >> We have a definition in place where currently icedtea is defined to be
> >> icedtea-7.
> >> I guess we could just flip that to icedtea-8, and check what still
> works.
> >> That would flip the version in the build system also, as it uses
> "icedtea".
> >>
> >> Should I check which packages are affected in advance, or just go with
> the
> >> build and see what does not work?
> >
> > Another way to check what packages we'll need to try to build is to use
> > "guix refresh", which uses some features of (guix graph) to display
> > information about dependent packages.  Here's what we get for icedtea-7:
> >
> > [0] marusich@garuda.local:~/guix
> > $ ./pre-inst-env guix refresh -l -e '(@ (gnu packages java) icedtea-7)'
> > Building the following 39 packages would ensure 202 dependent packages
> are rebuilt: sra-tools@2.8.2-1 minced@0.2.0 r-seurat@1.4.0.12-1.fccb77d
> ant@1.10.1 java-htsjdk@1.129 java-jdom@1.1.3 clojure@1.8.0
> java-osgi-service-jdbc@1.0.0 java-plexus-interpolation@1.23
> java-commons-daemon@1.0.15 java-commons-net@3.6 java-commons-cli@1.2
> java-commons-lang@2.6 java-jmh@1.17.5 tuxguitar@1.4
> java-commons-collections4@4.1 java-javax-mail@1.5.6 f-seq@1.1-1.6ccded3
> java-commons-beanutils@1.9.3 java-jgit@4.7.0.201704051617-r
> java-osgi-service-resolver@1.0.1 java-osgi-service-packageadmin@1.2.0
> java-osgi-service-cm@1.5.0 java-osgi-util-tracker@1.5.1 antlr3@3.5.2
> java-eclipse-team-core@3.8.0 java-httpcomponents-httpcore-ab@4.4.6
> java-httpcomponents-httpmime@4.5.3 java-httpcomponents-httpcore-nio@4.4.6
> java-plexus-container-default@1.7.1 kodi@18.0_alpha-6-f22d62d
> hdf-java@3.3.2 ruby-atoulme-antwrap@0.7.5 plantuml@8048
> java-guice-servlet@4.1 java-eclipse-jetty-servlet@9.4.6
> java-eclipse-jetty-servlet@9.2.22 icedtea-web@1.6.2 axoloti-patcher@1.0.12
> >
> >
> > So, I think we should probably do the following:
> >
> > 1) Confirm that these packages build before making changes.  If any
> > fail, fix them first if possible.
> >
> > 2) As you suggested, flip the icedtea variable to point to icedtea-8
> > instead of icedtea-7.
> >
> > 3) Repeat the builds, and see what fails.  Fix any new breakage.
> >
> > And of course, we should opportunistically clean up package definitions
> > as we go.
> >
> > I'm going to try step (1) tonight on my laptop.  Is there a way to check
> > their build status on Hydra, I wonder?  I'm planning to just do it in a
> > simple shell one-liner like the following:
> >
> > for pkg in $(</tmp/pkgs); do if guix build --keep-failed $pkg; then echo
> success: $pkg >> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done
> >
> > ...but I'm sure there is probably a more elegant way to accomplish the
> > same task.  Anyway, I'll let you know how it goes.
> >
> >> As first step it is not needed to remove #:jdk icedtea-8 references,
> >> because I think that simply becomes a noop. Am I right here?
> >> That can be done as the last step before merging, I guess.
> >
> > I think that's right, but I haven't looked closely yet, and Ricardo may
> > know more.
>
> Whoops!  I forgot to include Gábor on my last email, so I've included
> Gábor on this one.  Sorry about that.
>
> --
> Chris
>

[-- Attachment #2: Type: text/html, Size: 6704 bytes --]