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

[Gábor Boskovits]

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 <address@hidden>:

Chris Marusich <address@hidden> writes:

> Gábor Boskovits <address@hidden> 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] address@hidden:~/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: address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden0.1 java-osgi-service-address@hidden address@hidden address@hidden address@hidden address@hidden java-httpcomponents-httpcore-address@hidden java-httpcomponents-httpmime@4.5.3 java-httpcomponents-httpcore-address@hidden java-plexus-container-default@1.7.1 address@hidden address@hidden address@hidden address@hidden address@hidden address@hidden4.6 address@hidden2.22 address@hidden address@hidden
>
>
> 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