On 6/23/13 1:43 PM, Alexander Hansen wrote: > On 6/23/13 11:15 AM, Daniel Johnson wrote: >> >> On Jun 23, 2013, at 1:06 PM, Alexander Hansen >> <[email protected]> wrote: >> >>> On 6/23/13 8:45 AM, Alexander Hansen wrote: >>>> On 6/23/13 7:04 AM, Alexander Hansen wrote: >>>>> On 6/23/13 6:55 AM, Daniel Johnson wrote: >>>>>> >>>>>> On Jun 20, 2013, at 9:55 PM, Alexander Hansen >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> On 6/19/13 8:03 PM, Alexander Hansen wrote: >>>>>>>> 1) I've finally smoothed some tuits down enough to work on >>>>>>>> https://github.com/fink/fink/issues/42 . This is going use a >>>>>>>> similar >>>>>>>> methodology as the system-SDK packages, in that we're not going to >>>>>>>> have >>>>>>>> system-javaXY packages present at all for systems where one cannot >>>>>>>> possibly have that XY (e.g. system-java13 on Mountain Lion). >>>>>>>> Having a >>>>>>>> virtual package present but not installed produces a confusing faux >>>>>>>> build process when installing something that depends on it, whereas >>>>>>>> not >>>>>>>> having an entry for the package gives a straightforward "package >>>>>>>> does >>>>>>>> not exist" message. >>>>>>>> Once I've got something that WorksForMe on different platforms, >>>>>>>> I'll >>>>>>>> put >>>>>>>> it in a branch of the main fink repository. >>>>>>>> >>>>>>> >>>>>>> Meh, I just put it in master. User-visible changes are: >>>>>>> >>>>>>> 1) For people on 10.7 or later who have Oracle's Java-1.7.x >>>>>>> installed, >>>>>>> there will be system-java17* packages, plus the system-java and >>>>>>> system-java-dev package will exist for people who don't have a >>>>>>> legacy >>>>>>> Apple Java installed, e.g. people who installed Mountain Lion after >>>>>>> Apple dropped it. >>>>>>> >>>>>>> 2) On 10.5/i386, system-java16* goes away because Java-1.6.x was >>>>>>> distributed as x86_64 only for some reason there. >>>>>> >>>>>> Your commit bffa85c appears broken. I'm getting a lot of these every >>>>>> time I run fink: >>>>>> >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 420. >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 421. >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 427. >>>>>> Use of uninitialized value $dir in pattern match (m//) at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 433. >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 420. >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 421. >>>>>> Use of uninitialized value $dir in concatenation (.) or string at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 427. >>>>>> Use of uninitialized value $dir in pattern match (m//) at >>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 433. >>>>>> >>>>>> Looks like $dir is no longer in scope? >>>>>> >>>>>> Daniel >>>>>> >>>>> >>>>> Hmm...I'm not seeing that here, and I've got both a legacy and a >>>>> new JDK >>>>> so I thought I had full coverage :-) . >>>>> >>>>> What does "/usr/libexec/java_home -V" return? >>>>> >>>> >>>> And what OS version? >>>> >>> >>> $dir is still in scope at line 420. It gets redefined, and >>> potentially undefined, now that I look at it, at line 406 for 1.7.x >>> JDKs: >>> >>> ($dir) = ($javadir =~ m|jdk(\d.*)_|) ; >> >> >> I get >> >> Matching Java Virtual Machines (5): >> 1.7.0_06, x86_64: "Java SE 7" >> /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home >> 1.7.0_04, x86_64: "Java SE 7" >> /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home >> 1.7.0-u4-b05-20120111, x86_64: "OpenJDK 7" >> /Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home >> 1.6.0_51-b11-456, x86_64: "Java SE 6" >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home >> 1.6.0_51-b11-456, i386: "Java SE 6" >> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home >> >> /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home >> >> Interesting that I have multiple 1.7.0's showing. >> >> This is on 10.8.4 with Xcode 4.6.3. >> The issue goes away when I roll back to before the java commits. >> >> Daniel >> > > The issue would indeed go away, because 1.7.x isn't detected at all. :-) > > The multiple 1.7.0 JDKs is completely normal. This appears to be the > same strategy that has been used on Windows all along. > > (One annoyance is that the auto-update for Java (via the Control Panel) > seems only to update the browser plugin and not the JDK.) > > I have: > > $ /usr/libexec/java_home -V > Matching Java Virtual Machines (4): > 1.7.0_25, x86_64: "Java SE 7" > /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home > 1.7.0_21, x86_64: "Java SE 7" > /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home > 1.6.0_51-b11-456, x86_64: "Java SE 6" > /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > 1.6.0_51-b11-456, i386: "Java SE 6" > /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home > > and I naively assumed that the path structure wasn't changed along the way. > > So the issue appears to be that your OpenJDK and 1.7.0_4 JDK paths don't > satisfy the regex and $dir winds up getting unset.
I just made a change in master which _should_ work appropriately with those path names. Let me know. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ fink-core mailing list [email protected] List archive: http://news.gmane.org/gmane.os.apple.fink.core Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-core
