https://bugzilla.redhat.com/show_bug.cgi?id=1443076 --- Comment #21 from jiri vanek <jvanek@xxxxxxxxxx> --- (In reply to Mikolaj Izdebski from comment #20) > (In reply to jiri vanek from comment #19) > > (In reply to Mikolaj Izdebski from comment #16) > > > - if config is in /etc then you need to back up only this directory, /usr > > > is supposed to be restorable from package contents > > > > Any config file is, isnt? Even if it is in etc... > > If you modify config file, then how are you going to restore your (modified) > config from package contents? I see,you wont to restore it also with custom changes. That do not have much sense, does it? It requires different layer of backuping I was speaking about restoring the original file. That something yo do simply by rpm reinstall. > > > I see two issues > > - all javas up to now had configs in java_home, which in /usr/lib/jvm/theJdk > > - so if your concerns are applicable, then they have to be revisited > > Have to? Theoretically older Javas could use existing (non-FHS compliant) > location, but Java 9 could use the new location. Should. It is strange to have each JDK having different apporaches. > > > - config files were decided to be in jdk, as they are supposed to be jdk x > > cluster specific. So this is fundametnal chage to java in fedora/rhel. > > I don't see any fundamental change here. You would just move config files > from /usr to /etc and leave symlinks where config files used to be. No > functional changes, but you gain FHS compliance. it is quite hard to imagine. In this case, if you use fs with different /etc and, jdk may have those configs missing. Some of them are fundamental for its work and it will not survive theirs absence... > > > If we agreed on this, are you ok with simply symlinks? > > Yes, symlinks are perfectly fine. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
