Gábor Boskovits 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: --8<---------------cut here---------------start------------->8--- [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 --8<---------------cut here---------------end--------------->8--- 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: --8<---------------cut here---------------start------------->8--- for pkg in $(> /tmp/log; else echo failure: $pkg >> /tmp/log; fi; done --8<---------------cut here---------------end--------------->8--- ...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. -- Chris