pkg version confused by left-over port directories

[infracaninophile]

If a port is removed from the tree, but for whatever reason, the directory still exists on some system, it can lead to pkg version producing incoherent results. pkg version should examine the $SUBDIRS variable in category Makefiles to validate port viability.

From IRC:

[07:23]  <tigerby> hi guys
[07:24]  <tigerby> I have not watched bugtracker (yet) so..
[07:24]  <tigerby> I have question about pkg version :)
[07:25]  <tigerby> I have installed java/diablo-jdk16. pkg version -vL= : diablo-jdk-1.6.0.07.02_20          >   succeeds port (port has )
[07:26]  <tigerby> [tiger@laptop]:~%grep diablo-jdk16 /usr/ports/MOVED
[07:26]  <tigerby> java/diablo-jdk16|java/openjdk6|2012-12-10|Has expired: Outdated, consider using openjdk6 or openjdk7
[07:27]  <tigerby> but..
[07:27]  <tigerby> I have also: wine-fbsd64-diablo3-1.5.4,1        ?   orphaned: emulators/wine-fbsd64 and skype-2.0.0.72,1                   ?   orphaned: net-im/skype20
[07:27]  <tigerby> why in case diablo-jdk It show me " > succeeds port (port has )"
[07:32]  <tigerby> can't find a similar issue. but I'm not sure that is a bug :) any ideas ?
[07:37]  <infracaninophile> Ii's not typing a coherent message.  That's definitely a bug, but not a world-shaking one.
[08:02]  <infracaninophile> Hmmm.... do you have /usr/ports checked out on that machine? with an INDEX file present?
[08:08]  <tigerby> yep
[08:10]  <tigerby> hehe. Long time ago I install diablo-jdk16 via `make install`, without clean, after that I update ports tree, and I have java/diablo-jdl16/work
[08:10]  <tigerby> after rm -fr and `pkg version -vL=` I see "diablo-jdk-1.6.0.07.02_20          ?   orphaned: java/diablo-jdk16" :)
[08:14]  <infracaninophile> Interesting.  The presence of /usr/ports/java/diablo-jdk16/ on your machine shouldn't matter if the corresponding entry in /usr/ports/java/Makefile has been removed. 

[bapt]

I think checking for SUBDIR is wrong some may have custom ports not in there.
Probably the right thing to do is check if there is a Makefile in the directory, as well as checked the return value of executed make command, that will be faster as well

[andrejzverev]

Why don't cache result of make -VSUBDIR? negative effect of such cache is a memory consumption.

[bapt]

Which might be very small any, yes caching is the solution imgo
Le 26 juil. 2014 13:41, "andrejzverev" notifications@github.com a écrit :

Why don't cache result of make -VSUBDIR? negative effect of such cache is
a memory consumption.

—
Reply to this email directly or view it on GitHub
#408 (comment).

[bapt]

that has been done