hi!

I'm a bit confused by this report, as the alternatives handling had (nearly) not  changed.

The differences between f20 and f19 package are two:
 - jre was split to headless and "rest".
 - the alternatives do not forcibly change after update  if you are already on manual mode


From your report it is not clear which caused the issue. From first, it seems that headless (the more important with java command and alternatives logic) part of jre was not installed. It would be critical if it did not. 

The second part looks even more strange - the "/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java" alternatives record should not exist at all!

I hope, that your issue was caused by alternatives in manual mode for longer time (remaining item in alternatives) and so not changed alternative after dist update.

Anyway will need more investigations on both yours an (especially)my side.

> it seems that headless  part of jre was not installed

as you can also see above both are there and updated
java-1.7.0-openjdk.x86_64 1:1.7.0.60-2.4.3.4.fc20          
java-1.7.0-openjdk-headless.x86_64 1:1.7.0.60-2.4.3.4.fc20

> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

nonsense

/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java *should exist* and not only the fullversioned /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.4.fc20.x86_64/jre/bin/java which changes with every update

> caused by alternatives in manual mode for longer time

pretty sure, the machine was originally instaleld with F14

i do not need the whole alternatives crap but it's impossible to work with manual symlinks too if install folders are full versioned which is complete nonsense in case of normal packages which can be installed only in one version at any point of time

(In reply to Harald Reindl from comment #2)
> > it seems that headless  part of jre was not installed
> 
> as you can also see above both are there and updated
> java-1.7.0-openjdk.x86_64 1:1.7.0.60-2.4.3.4.fc20          
> java-1.7.0-openjdk-headless.x86_64 1:1.7.0.60-2.4.3.4.fc20
> 
> > /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
> 
> nonsense

nope. Sense. All alternatives are now linked directly via fully versioned path.

This is necessary to have multiple eopenjdk7 installed.

The link you wont is outdated. You can remove it.
> 
> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java *should exist* and not only
> the fullversioned
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.4.fc20.x86_64/jre/bin/java
> which changes with every update
> 
> > caused by alternatives in manual mode for longer time
> 
> pretty sure, the machine was originally instaleld with F14

Yes, I see the case now. Since you have alternatives on manual, and you have the legacy symlink, then f20 's openjdk do not update the alternatives.

What happened:
 You have the legacy synlink
 F19's jdks always removed previous one, and set last installed jdk's java/javac as alternatives target 
 you updated on f20 - the previous installation (and its links) disapeared, the legacy one remained, and was set as main. 
 you have alternatives on manual, so newly added record was not set as target for java/javac

If you remove the legacy symlinkt he alternatives should work for you as expected.

Sorry for inconvenience. I was removing this symlink several times, but looks like this update somehow avoided you.
> 
> i do not need the whole alternatives crap but it's impossible to work with
> manual symlinks too if install folders are full versioned which is complete
> nonsense in case of normal packages which can be installed only in one
> version at any point of time

You are trying to use  the installation out of the current box:

You should use only the links:
 - /usr/bin/{java,javac...}
 - /usr/lib/jvm/{java,java-1.7.0,java-1.7.0-openjdk,java-1.7.0-openjdk.arch,java-openjdk,similarForJre} 
 - jre and sdk as set by alternatives

If yo confirm "What happened"+workAround then I will close this as "not a bug".
It will probably happen anyway once I will double check.

Once sorry for inconvenience. I was really trying to cleanup the alternatives  during f14-f20 lifetimes, but some cases could escape.

> This is necessary to have multiple eopenjdk7 installed

oh my god - hopefully we go not in the direction Sun was for years that old and vulnerable JRE's where not removed by updates.......
_______________________

remove *which* "legacy symlink"

i have no single idea why alternatives links to /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java after the update because it was using the named one already because the breakage happened due the dist-upgrade the first time

i already fixed that once by alternatives --config java

so *what* file/link to remove that in the future it does not happen again

(In reply to Harald Reindl from comment #4)
> > This is necessary to have multiple eopenjdk7 installed
> 
> oh my god - hopefully we go not in the direction Sun was for years that old
> and vulnerable JRE's where not removed by updates.......

no!

Updates are working correctly. Once you update, old jre is removed.

This feature is based on rpm -i. You can add custom jdk based on current packages.

It may sound strangely to you but it was requested by many users.
> _______________________
> 
> remove *which* "legacy symlink"
> 
> i have no single idea why alternatives links to
> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java after the update because it
> was using the named one already because the breakage happened due the
> dist-upgrade the first time
> 
> i already fixed that once by alternatives --config java
> 
> so *what* file/link to remove that in the future it does not happen again

remove this one: *+ 1           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

> remove this one: *+ 1 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

what the hell - this one does not exist at all and that is why it is clearly a bug that it is offered and even set as default after each and every update

[root@rh:~]$ stat /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
stat: cannot stat '/usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java': No such file or directory
[root@rh:~]$ alternatives --config java

There are 2 programs which provide 'java'.

  Selection    Command
-----------------------------------------------
*  1           /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java
 + 2           /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.4.fc20.x86_64/jre/bin/java

Enter to keep the current selection[+], or type selection number:

Please, remove all alternatives records which do not point to fully versioned directories, or to another alternatives  - like   /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

if i would know from where it takes /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java i would have removed it instead write a bugreport

I'm not sure if we understand each other.

existence of link of /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/ is meaningless. 
Whether it exists or not, you can unlink it or let it be.

Important is record in alternatives. So please remove it:

sudo alternatives   --remove java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java

Also please check if you do not have similar relics under keys of:
jre_1.7.0
javadocdir
jre_openjdk
jre_1.7.0_openjdk
java
java_sdk_1.7.0_openjdk
java_sdk_openjdk
java_sdk_1.7.0
javac

> I'm not sure if we understand each other

i am not working daily with "alterantives", frankly i would not need 
it at all and that's why even as i am software developer did not
know how to get rid of this problem until your post with "alternatives --remove java /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java", hence that is why this should be done by the update itself

Sure!

 After you removed the legacy entries, the update should handle it on its own.
 Sorry that the "clean up code" of old alterantives have not affected your system.


Please, when you do another update  sucess, close the bug (unless I will do it first)

i will give feedback after the next openjdk-update