thesamesam
commented
1 year ago does it say that a stable package must have a way to satisfy its dependencies with only stable packages, or does it say that a stable package may not have a way to satisfy its dependencies with any unstable package.
A stable package must have a way to have its dependencies satisfied by only stable packages. It's fine if unstable packages satisfy that too. This happens all the time.
the-horo
With recent changes to toolchain.eclass, gcc's (and by extension gdc's) install directory has been changed (https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n172). Now, instead of the 3 version component, the directory path is only formed from the major version.
This would mean that gdmd dependency becomes any gcc in a certain slot. dlang.eclass is updated to reflect that, in addition, any package build with gdc will depend on both it and gdmd. The gdmd dependency should be build time only, which is not the case currently.
This approach has only 1 problem, that of a stable gdmd depending on an unstable gcc. If the user had an unstable gcc installed and then either installed gdmd or a package with USE=gdc-*, gdmd would be dependant on that unstable version of gcc, which goes against Gentoo policy. This, however, becomes a problem only when stabilising gdmd, so, in its current state of being unstable on all arches, as well as all gdc targets being unstable, will be fine.
However, I am uncertain on how this policy should be interpreted, does it say that a stable package must have a way to satisfy its dependencies with only stable packages, or does it say that a stable package may not have a way to satisfy its dependencies with any unstable package. This question is important because it dictates how gdmd's keywords are to be stabilised based on gcc's.
Another approach would be to have a seperate gdmd version for each compiler release, having the same keywords so no discrepancy could happen. Yet, this would involve a lot of gdmd versions, as well as frequent stabilisations and bumps. This can be achieved with automation, but, for now, to get any solution in place, the gdmd-slot.ebuild approach makes the most sense.