>=dev-lang/dmd-2.068 circular dependency on itself

[hartwork]

In relation to #53 I was about to re-install dmd and gtkd, but:

# sudo emerge dev-libs/gtkd
[..]
These are the packages that would be merged, in order:

Calculating dependencies... done!


[ebuild  N     ] dev-libs/gtkd-3.5.1:3::dlang  USE="dmd-2_073 opengl static-libs -dmd-2_066 -dmd-2_067 -dmd-2_068 -dmd-2_069 -dmd-2_070 -dmd-2_071 -dmd-2_072 -gdc-4_8_5 -gdc-4_9_4 -gstreamer -ldc2-0_15 -ldc2-0_16 -ldc2-0_17 -ldc2-1_0 -ldc2-1_1 -peas -sourceview -vte" ABI_X86="(64) -32 (-x32)" 4,107 KiB
[ebuild  N     ]  dev-lang/dmd-2.073.2:2.073::dlang  USE="dmd-2_073 static-libs -dmd-2_067 -dmd-2_068 -dmd-2_069 -dmd-2_070 -dmd-2_071 -dmd-2_072 -doc -examples -gdc-4_9_4 -ldc2-0_16 -ldc2-0_17 -ldc2-1_0 -ldc2-1_1 -tools" ABI_X86="(64) -32" 19,918 KiB

Total: 2 packages (2 new), Size of downloads: 24,025 KiB

 * Error: circular dependencies:

(dev-lang/dmd-2.073.2:2.073/2.073::dlang, ebuild scheduled for merge) depends on
 (dev-lang/dmd-2.073.2:2.073/2.073::dlang, ebuild scheduled for merge) (buildtime_slot_op)

 * Note that circular dependencies can often be avoided by temporarily
 * disabling USE flags that trigger optional dependencies.

Could it be that dmd depending on itself is new and happended by mistake? dmd was installable out of the blue recently, as far as I remember.

Best, Sebastian

[mleise]

It is normal that dmd:2.073 compiled with USE=dmd-2_073 pulls in dmd:2.073 as a dependency. Try to compile dmd with an already installed Dlang compiler or one of the long-term support "bootstrap" compilers that are still written entirely in C++. E.g. dmd-2.067 or ldc2-0.17.
An option to self-host dmd using the binaries provided by upstream is planned via a default enabled "self-host" USE flag.

[hartwork]

Thanks for the hint on dmd-2.067. That's a tricky situation for the user I must say. I wonder if something like || ( <=dev-lang/dmd-2.067 >dev-lang/dmd-2.067 ) or so could trick the dependency resolver into finding a non-loop combination to bootstrap.

[mleise]

I don't think the dependency resolver could do anything about it. I mean, as soon as the dmd-2_073 USE flag is set, dmd-2.073 (in any revision) is pulled in as dependency and the dmd to be compiled is about to be linked against an installed libphobos 2.073.

[mleise]

Dmd is now installable out of the blue on Linux (and in theory FreeBSD) using the pre-compiled binaries shipped with the source distribution. This behavior is enabled by not selecting any compiler USE flags, which was previously an error.

[hartwork]

I noticed that if you you start from zero emerging an app like x11-terms/tilix you need to pick a compile flag like dmd-2_074. Now the users has too know to not put that into make.conf but only into package.use so that dmd doesn't get USE=dmd-2_074 passed as well and fails. I think that's still rather tricky for users. Any ideas on taking that edge off as well?

[mleise]

No idea really. I can turn "dmd-2_074" into just "dmd" for entirely static builds, but that doesn't change the dependency on an already installed dmd as soon as you enable the "dmd" USE flag in make.conf. Should I prefix the compiler USE flags for dmd, so they need to be set separately? Then we'd also need to maintain two USE flag description lists in the overlay's metadata.
We could also investigate adding an additional dmd-bin package, and see if that takes precedence in case that dmd has a circular dependency.
Do you have an idea?

[hartwork]

I have a vague memory that in || ( one two three ) order matters, i.e. if all are missing, the first should be the one pulled in. I think that may work.

[mleise]

Thank, I'll have a look when I decide to drop the explicit version dependencies for the compiler. For now it works as expected unless portage learns to magically emerge the same package twice with different USE flags:

These are the packages that would be merged, in order:
dev-lang/dmd-2.073 USE="dmd-2.067"
dev-lang/dmd-2.073 USE="dmd-2.073"