`dub upgrade --missing-only` and `git+https` selections can lead to multiple package cache entries

[kinke]

trafficstars

pkg1/dub.sdl:

name "pkg1"
targetType "library"
dependency "openssl" version=">=3.1.0"

pkg2/dub.sdl:

name "pkg2"
targetType "executable"
dependency "pkg1" path="../pkg1"

pkg2/dub.selections.json:

{
	"fileVersion": 1,
	"versions": {
		"openssl": {"repository":"git+https://github.com/kinke/openssl.git","version":"9e56c4bd28d01bcd3644df940101f156b48d9fca"},
		"pkg1": {"path":"../pkg1"}
	}
}

After cleaning up the ~/.dub/packages cache, running dub upgrade --missing-only with dub v1.28 in the pkg2 dir yields two identical openssl git clones:

1. ~/.dub/packages/openssl-9e56c4bd28d01bcd3644df940101f156b48d9fca/openssl
2. ~/.dub/packages/pkg1-9e56c4bd28d01bcd3644df940101f156b48d9fca/pkg1

dub build is fine, only ending up with expected version 1 above.

[nordlow]

After cleaning up the ~/.dub/packages/ cache

What is meant by this line?

If it is meant that ~/.dub/packages/ is deleted where do the other faulty cache artifacts reside? In pkg1/.dub/ or pkg2/.dub/ or both? Or under /tmp/?

[kinke]

An rm -rf ~/.dub/packages, just to illustrate that the 2 resulting clones are both caused by the following dub cmdline, not some leftover from other builds. Not recommended for local reproduction. ;)

[nordlow]

An rm -rf ~/.dub/packages, just to illustrate that the 2 resulting clones are both caused by the following dub cmdline, not some leftover from other builds. Not recommended for local reproduction. ;)

I see, thanks.

[nordlow]

2. ~/.dub/packages/pkg1-9e56c4bd28d01bcd3644df940101f156b48d9fca/pkg1

Should the hash on this line differ from previous?

[nordlow]

Do you have any clues about where to start digging to fix this, @s-ludwig?

[rikkimax]

I would look at: https://github.com/dlang/dub/blob/e4648047ad8cb1595a56b64a799eb922e99576bc/source/dub/packagemanager.d#L289

[nordlow]

So to double check is the call to git clone getting the wrong treehash, @kinke? Regardless of cloning over git vs https, right?

[kinke]

Nope - there should obviously be no pkg1-9e56c4bd28d01bcd3644df940101f156b48d9fca dir at all, with an openssl hash and containing a superfluous openssl clone!

[WebFreak001]

was a mixed up argument in the package resolver. Has been fixed by #2588 since v1.31.1-beta.1