Bug 204989 - java/javavmwrapper: a symbolic link created by registervm conflicts with sysutils/jps
Summary: java/javavmwrapper: a symbolic link created by registervm conflicts with sysu...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Greg Lewis
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-03 09:56 UTC by Dave Cottlehuber
Modified: 2018-03-23 17:56 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (pavel)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Cottlehuber freebsd_committer 2015-12-03 09:56:14 UTC
openjdk8 (or possibly javavmwrapper) has a softlinked /usr/local/bin/jps to /usr/local/bin/javavm which appears to be unknown to pkg:

❯sudo pkg install -y openjdk8-8.60.24 ....

❯pkg which /usr/local/bin/jps
/usr/local/bin/jps was not found in the database

❯which jps
/usr/local/bin/jps

❯l /usr/local/bin/jps
lrwxr-xr-x  1 root  wheel    21B Dec  3 09:46 /usr/local/bin/jps@ -> /usr/local/bin/javavm

This conflicts when installing sysutils/jps.

BTW should pkg complain when it overwrites an existing file silently, even if it's not somehow in the pkg database? This is actually what happened that caused me to dig into this.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2015-12-04 02:37:41 UTC
Fix Summary and assign correctly.
Comment 2 pavel 2015-12-29 20:43:56 UTC
What would be an appropriate fix by your opinion?

The standard install utility used to install package files for sysutils/jps usually either owerwrites files or may rename them if there is an option set.

The same way as many packages do, although the current install sheme mignt have changed since the latest port update.
Comment 3 Dave Cottlehuber freebsd_committer 2016-01-07 21:33:33 UTC
Hi Pavel, as a new comer to FreeBSD my POLA was that:

1. all files,links,resources installed by a package should be registered in pkg db
2. conflicting pkg/ports should be marked as such (or resolved!)
3. pkg itself should warn or possibly fail to install conflicts unless --force or similar flag is given

I see 2 things to do here:

1. decide what, if anything to do about POLA#1 for openjdk8, assuming pkg can track softlinks.

2. decide what to do about POLA#2 and POLA#3 for pkg. I can raise another ticket if required but I'd like to see one of the pkg people at least comment on this thread first.

Sounds sensible to you?
Comment 4 Jung-uk Kim freebsd_committer 2016-01-07 22:25:30 UTC
Re-assign to the maintainer.
Comment 5 Greg Lewis freebsd_committer 2016-01-21 05:48:08 UTC
It's not the openjdk8 package itself that creates these links.  The openjdk8 package execs javavm's registervm as part of installing itself.  It is that which creates the symlinks.

I can't think of a simple way for the package to handle this.  If its a problem then the best thing to do is to create a CONFLICTS entry for the two.

Note that installing openjdk7 or openjdk6 will have the same effect.
Comment 6 Kurt Jaeger freebsd_committer 2016-02-06 17:15:13 UTC
jps used in many systems for java processes. So I thing sysutils/jps should rename the jps program, if possible.
Comment 7 Dave Cottlehuber freebsd_committer 2016-04-18 11:38:57 UTC
I submitted a trivial patch for CONFLICTS against sysutils/jps.
What is the best way to handle this for the various *jdk ports?

java/openjdk6/
java/openjdk6-jre/
java/openjdk7/
java/openjdk7-jre/
java/openjdk8/
java/openjdk8-jre/
Comment 8 Dave Cottlehuber freebsd_committer 2016-11-06 10:00:11 UTC
To avoid this ticket festering, I will push to get the jps CONFLICTS
patch committed, but for me there are still unanswered questions from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204989#c3

- should the various jdk packages somehow inform pkg(8) of their use of  /usr/local/bin/jps or not? 

- does it make sense to add a CONFLICTS to the openjdk packages too?
Comment 9 w.schwarzenfeld freebsd_triage 2018-03-23 17:56:59 UTC
Is this still relevant?