Updating : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.2.5.fc20.i686 8/64 warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/US_export_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/US_export_policy.jar.rpmnew warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/local_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/local_policy.jar.rpmnew Todays update! I have never seen a *.jar file being rpm'newed. Neither did I alter or touched that file so an update should go seamless and shouldn't require this kind of action. By the way: Please fix!
I did the update again today with a fresh backup: ;------------------------------------------------------------------------------- Updating : libgcc-4.8.3-7.fc20.i686 24/100 Updating : libstdc++-4.8.3-7.fc20.i686 25/100 Updating : 1:java-1.7.0-openjdk-headless-1.7.0.65-2.5.2.5.fc20.i6 26/100 warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/US_export_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/US_export_policy.jar.rpmnew warning: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/local_policy.jar created as /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i386/jre/lib/security/local_policy.jar.rpmnew Updating : 1:java-1.7.0-openjdk-1.7.0.65-2.5.2.5.fc20.i686 27/100 ;------------------------------------------------------------------------------- The old version being updated is: ;------------------------------------------------------------------------------- ---> Package java-1.7.0-openjdk.i686 1:1.7.0.65-2.5.2.4.fc20 will be updated ---> Package java-1.7.0-openjdk.i686 1:1.7.0.65-2.5.2.5.fc20 will be an update ---> Package java-1.7.0-openjdk-headless.i686 1:1.7.0.65-2.5.2.4.fc20 will be updated ---> Package java-1.7.0-openjdk-headless.i686 1:1.7.0.65-2.5.2.5.fc20 will be an ;------------------------------------------------------------------------------- The jre/lib/security directory contains 2x the same policy files. Since this is a new java version with new versioning, then this explains that the 2.5.2.5 directory isn't available at that time (or in an earlier backup). So I am curious how the files can be installed twice. Once as the *.jar file and then a moment later create the same file again (same size) and name them *.jar.rpmnew This clearly is a packaging issue.
Hi! Was there something other then *_policy.jar "rpmnewed" ? If not, then I'm afraid this is candidate to not a bug, becaase it is expected behaviour. The policy jars are regenerated every build, but are marked as config(noreplace) in specfile, because they are supposed to be overwritten by user. And once they are overwritten by user they must not be replaced by RPMs. On contrary, they are regenerated on purpose, as underlying files could have change. Well, if only those two were rpmnewd, then this is really not a bug. However, from long term - I mean for jdk8 and onwards, Those files should be generated in RPM without timestamp to try to minimize need of overwrite after each update (and so overwrite only when real content change) . But it will be different bug. Very probably to Openjdk bugzilla.
How was this handled the 100000 updates of java-openjdk that arrived on my system since Fedora 16 ? None of these updates rpmnew'ed anything. I have no idea about config(noreplace) or things like this. See me as a consumer that relies on a working java-openjdk installation. By the way, I don't overwrite anything I don't even touch the java directories. The rpmnew'ed files show up in a NEW directory after java-openjdk 2.5.2.5 get depacked. This directory and it's contents never existed until rpm -i touched the stuff for installation. No bug ? I don't take this.
Maybe the QS people might want to comment on it ?
(In reply to Ali Akcaagac from comment #3) > How was this handled the 100000 updates of java-openjdk that arrived on my > system since Fedora 16 ? > > None of these updates rpmnew'ed anything. I have no idea about Thats surprise me. Because this is in for looong time. > config(noreplace) or things like this. See me as a consumer that relies on a > working java-openjdk installation. By the way, I don't overwrite anything I > don't even touch the java directories. You dont. but other may. > > The rpmnew'ed files show up in a NEW directory after java-openjdk 2.5.2.5 Thats correct. each jdk appears in new directory. And yes, all config files you had, are copied into new dirrectory. > get depacked. This directory and it's contents never existed until rpm -i > touched the stuff for installation. > > No bug ? I don't take this.
(In reply to jiri vanek from comment #5) > Thats correct. each jdk appears in new directory. And yes, all config files > you had, are copied into new dirrectory. The behaviour I remember is that ALL config files I had - altered - will be saved as *.rpmsave during uninstall. During an update ALL config files I had - altered - will be left intact and possible NEW config files will be named as *.rpmnew, so one can diff through them and apply the changes if applicable. None of those happened here. I haven't had changed any older or new config files (named the ones above), therefore through an update I expect this: Point 1) * The OLD *.jar files including the old package should be removed. This is my expected behaviour, since I haven't touched anything. * In case the old package has some altered *.jar files with the same name as the package provides, that these files are being left intact with *.jar.rpmsave in the directory that the OLD package was in. In my case 2.5.2.4. Since this is not the case the old 2.5.2.4 directory got nuked entirely -> expected behaviour. Point 2) * Usually during an update you replace config files inplace and if they get altered manually the new ones will be named *.rpmnew. If the config files were not altered then the correct behaviour is to replace the old untouched config files with the new ones. So only manually or automated changes of the config files that got provided by the rpm package get either an *.rpmsave during uninstall or the new config files being named *.rpmnew during install or update. So what I understand from your writing is this: Your script copies over the said *.jar files (which has never been touched by me or anything else). Your package tries to install the new java and detects that you previously copied over these *.jar files and thus names the same *.jar files *.jar.rpmnew. Why ? The 2.5.2.5 directory never existed. Thus there is nothing to be copied over from an old java version to a new java version without explicit user interaction. Therefore this should never had happened. If you want to explicit deal with user changed configuration files then simply LEAVE the files renamed as *.rpmsave in the old directory. The user who is able to alter these configurations there, can copy them over on his own. So what I am trying to say is that the entire behaviour how java deals with this is somehow, how I won't expect it.
Simple example: 2.5.2.4/jre/somedir/config.cfg <--- installed by your old rpm the file is say 120bytes and has a checksum 0x22334455 When I uninstall the 2.5.2.4 release and rpm detects the same bytes, checksum or whatever then it removes this file. Say I altered the file and the new size is 122bytes and has a checksum 0x2341231 During an uninstall the 2.5.2.4 release will remove everything else but leaves this file in the directory renamed as config.cfg.rpmsave 2.5.2.4/jre/somedir/config.cfg.rpmsave So I can enter this directory and rescue the config file or manually nuke it. The copy over thing is - to my understanding - wrong. Let's say the above example should keep the config.cfg.rpmsave intact. Now the problematic part here is that you give java a new directory everytime you update. Is it an update or is is technically a new installation ? So if you say "your config" then I expect this to happen during a java update. Let's say I altered config.cfg then this is what I expect as result from a 2.5.2.4 to 2.5.2.5 update: ;-------------- 2.5.2.4/jre/somedir/config.cfg.rpmsave 2.5.2.5/jre/somedir/config.cfg ;-------------- There is NO config.cfg.rpmnew because you never replaced anything. It's an old file in an old directory. Things would look differently if you had a scenario like this: /etc/jre/somedir/config.cfg <--- original file from 2.5.2.4 (not touched) after an update this file is being deleted through rpm and replaced by the new file. The expected result would be like this: /etc/jre/somedir/config.cfg <--- original file from 2.5.2.5 (not touched) In case I nuke the package the file get removed. Different if this is the case: /etc/jre/somedir/config.cfg <--- changed file from 2.5.2.4 (touched) after an update the 2.5.2.5 package realizes (through rpm I believe) a different config file (even doesn't match the config file provided by 2.5.2.4) then the expected result is: /etc/jre/somedir/config.cfg <--- changed file from 2.5.2.4 (touched) /etc/jre/somedir/config.cfg.rpmnew <--- original file from 2.5.2.5 (not touched) In case I am wrong, you might correct me.
You mixed several topics here. However your description is quite correct. - first topic - the *policy.jar rmnew file - however strange this seems, those are config files. And although they are regenerated each build, they keep stmap config(norepalce). So original assignment of this bug really is close->not a bug. However see this bug - https://bugzilla.redhat.com/show_bug.cgi?id=1142153 - the consequence: - another topics you raised: In behaviour you are describing in last two comments is different issue. And you are right in almost all issues you picked Problem is, that I don't know any sensible solution which do not have side effects. yes, each jdk is installed into separate directory. This allows you not only multilib, but also to have multiple versions of jdk installed. This feature was heavily wonted by OpenJDK comunityand I like/sue it too. The side effect was, that config files did not survive update - https://bugzilla.redhat.com/show_bug.cgi?id=1038092 There were solutions how to fix this, and the winner was script in pretrans, which copy selected files to new location, so rpm handle those correctly. The side effects are what you describe. Another side effect was that that rpmsave fiels were actualy presented two times. And I was so spammed by compalints that I added rm on uninstalled directory. It is not nice, I agrre, but it silneced the swarm. However, now another group f people - and yo are speaking well and clearly for them - hit the issue from different side:( Unluckily the shared directory is not an solution. There are bugs in bugzilla for each of those issue. I wil try to recall them and search them, but by quick glance I have not fund.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.