GNOME Bugzilla – Bug 750533
Non root installs fail
Last modified: 2021-05-17 15:40:19 UTC
This bug relates to bug 737124 but has a more straightforward fix.
Created attachment 304737 [details] [review] patch to address bug
Reopening as although this fixed the bug it introduced a problem for root installs which needs to be addressed
Created attachment 305232 [details] [review] patch to fix bug
Maybe I'm wrong, but it seems to me that some files are not being installed properly. java-atk-wrapper.jar was installed in /root/.local/usr/lib/jvm/java-7-jdk/jre/lib/ext but I think that it should be installed at /usr/lib/jvm/java-7-jdk/jre/lib/ext. A similar observation to the file accessibility.properties. Am I doing something wrong?
(In reply to Jose Vilmar Estacio de Souza from comment #4) > Maybe I'm wrong, but it seems to me that some files are not being installed > properly. > > java-atk-wrapper.jar was installed in > /root/.local/usr/lib/jvm/java-7-jdk/jre/lib/ext but I think that it should > be installed at /usr/lib/jvm/java-7-jdk/jre/lib/ext. > A similar observation to the file accessibility.properties. > > Am I doing something wrong? What build commands are you running?
(In reply to Magdalen Berns (irc magpie) from comment #5) > (In reply to Jose Vilmar Estacio de Souza from comment #4) > > What build commands are you running? .//autogen --prefix=/usr make sudo make install
(In reply to Jose Vilmar Estacio de Souza from comment #6) > (In reply to Magdalen Berns (irc magpie) from comment #5) > > (In reply to Jose Vilmar Estacio de Souza from comment #4) > > > > > What build commands are you running? > > .//autogen --prefix=/usr > make > sudo make install Are you logged in as root when you perform this commands?
(In reply to Magdalen Berns (irc magpie) from comment #7) > Are you logged in as root when you perform this commands? No, the last command 'make install' was executed using the sudo, but the previous were not.
(In reply to Jose Vilmar Estacio de Souza from comment #8) > (In reply to Magdalen Berns (irc magpie) from comment #7) > > > Are you logged in as root when you perform this commands? > > No, the last command 'make install' was executed using the sudo, but the > previous were not. OK thanks for the info. If you're running make as sudo then running sudo ./autogen.sh --prefix=/usr should get things installed in the right way for a root install.
(In reply to Magdalen Berns (irc magpie) from comment #9) > > OK thanks for the info. > > If you're running make as sudo then running sudo ./autogen.sh --prefix=/usr > should get things installed in the right way for a root install. Ok, works fine. sudo ./autogen.sh --prefix=/usr sudo make sudo make install Seems that the files were installed correctly. In my opinion, only 'make install' should be executed as root.
(In reply to Jose Vilmar Estacio de Souza from comment #10) > (In reply to Magdalen Berns (irc magpie) from comment #9) > > > > OK thanks for the info. > > > > If you're running make as sudo then running sudo ./autogen.sh --prefix=/usr > > should get things installed in the right way for a root install. > > Ok, works fine. Thanks for getting back to me about this. > sudo ./autogen.sh --prefix=/usr > sudo make > sudo make install > > Seems that the files were installed correctly. I have set it up this way to avoid the non-root install failure triggered when trying to write properties and jar files to system java directories which don't provide permission for ordinary users. A similar issue affects 'make distcheck' too (see bug 737124) > In my opinion, only 'make install' should be executed as root. Off hand, I can't think of a reason for that and it seems like something that could be awkward to implement for the aforementioned reasons but I want to keep an open mind: Do you have a compelling reference on this which could persuade me that setting things up that way could improve the wrapper in some way?
(In reply to Magdalen Berns (irc magpie) from comment #11) > > In my opinion, only 'make install' should be executed as root. > > Off hand, I can't think of a reason for that and it seems like something > that could be awkward to implement for the aforementioned reasons but I want > to keep an open mind: Do you have a compelling reference on this which could > persuade me that setting things up that way could improve the wrapper in > some way? No, I have no strong argument, just that I do not like to run commands as sudo.
(In reply to Jose Vilmar Estacio de Souza from comment #12) > (In reply to Magdalen Berns (irc magpie) from comment #11) > > > In my opinion, only 'make install' should be executed as root. > > > > Off hand, I can't think of a reason for that and it seems like something > > that could be awkward to implement for the aforementioned reasons but I want > > to keep an open mind: Do you have a compelling reference on this which could > > persuade me that setting things up that way could improve the wrapper in > > some way? > > No, I have no strong argument, just that I do not like to run commands as > sudo. Why run sudo make install in this case? If you want to do a non-root install dropping the "sudo" command from the "make install" command should allow you to do this without the build breaking once you have cleaned up your previous install.
Created attachment 305935 [details] [review] patch to tidy up logic
Created attachment 307018 [details] [review] Don't use hard path for HOME install I've arbitrarily decided on $(HOME)/.local/share/java-atk-wrapper for home installs and this is not ideal. Given that it's not possible for a non root user to install jars and property files into the $JAVA_HOME directory and java does not search the /usr/local sub directory paths by default, it seems to make more sense to either make the user set JAVA_HOME for non-root installs or at least avoid hard coding paths in this way. - I think it makes sense to go with the latter for at least until I can think of a better way of getting around the annoyingness...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/java-atk-wrapper/-/issues/14.