https://bugzilla.redhat.com/show_bug.cgi?id=1443076 --- Comment #25 from Severin Gehwolf <sgehwolf@xxxxxxxxxx> --- (In reply to jiri vanek from comment #24) > (In reply to Severin Gehwolf from comment #23) > > (In reply to jiri vanek from comment #22) > > > > > > > > > > > If we agreed on this, are you ok with simply symlinks? > > > > > > > > > > Yes, symlinks are perfectly fine. > > > > > > Just to ensure convention, those are links, where source (target) is lying > > > inside jdk, and the link is in /etc/java-9-openjdk/NVRA > > > > It should be the other way round: > > > > ls -l /usr/lib/jvm/java-9-openjdk-NVRA/conf > > > > /usr/lib/jvm/java-9-openjdk-NVRA/conf -> /etc/java-9-openjdk/NVRA > > I thought so, but, I might be missing something about /etc mounting in > education... To quote Mikolaj: """" There are several valid reasons for keeping config files in /etc: - /usr may be read-only, but users should be allowed to edit config files - /usr may be shared between many machines, may use different Java config - if config is in /etc then you need to back up only this directory, /usr is supposed to be restorable from package contents >From FHS: "/usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere". So yes, config files definitely don't belong in /usr """" It's not /etc that's shared between machines. It's /usr which sometimes gets mounted. In that scenario it's expected for /etc/java-9-openjdk/ to contain every NVRAs config that are installed via mounted /usr/lib/jvm. /etc would have to get replicated across all machines. But yes, in the mounted /usr scenario, if there is a mismatch between /etc and what's installed via the /usr mount then things break. That's expected. The common use-case for such set-ups is for the NFS-shared host to do RPM installs and consumers of the NFS-share get config synchronized via version control. I.e. they don't install via RPM directly. -- 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
