Thoughts about D package management on Gentoo

[Wyatt]

On Sunday, 10 November 2013 at 18:14:25 UTC, Marco Leise wrote:
> Yeah, and they hopefully don't use Gentoo... maybe it is time
> to drop that version if it causes trouble. I'll try to have
> at least an dmd-1.076 ebuild though. It is also a good test
> for the whole multiple versions at once idea.
>
See, this is one of those times where it might have been nice if 
D2 had gone with dmd2 for its binary name.  Regardless, if you 
want to support D1, make it a slot, and mask it for all arches-- 
we don't exactly want to encourage its use at this point, IMO.  
This would be in the same general vein as dev-lang/dmd-bin (in 
the main tree, but terribly out-of-date).

Now, if it does get installed...an idea, though not a great one: 
If you look at mplayer and mplayer2, they both install roughly 
the same stuff to the same locations in their default 
distribution.  i.e. the binary is called mplayer in both the 
original and the fork.  So what happens in 
media-video/mplayer{,2} is mplayer2's stuff is renamed to match 
the $PN and there's an IUSE+=" symlink".  The symlink flag causes 
portage to install symlinks to the original mplayer stuff for 
transparent compatibility with various frontends and other stuff.

> Too many smilies, hehe. Well, it should be possible to have at
> least one installable version of every package at any time.
> Unless that package hasn't been updated for 10 months or so.
> I don't want to run into a situation where you can't update
> dmd because some application isn't updated or where I do
> update dmd early and D programs can't be installed any longer
> until they work with that latest version of D.
>
My understanding was we were fixing the soname versioning for 
phobos, so this should theoretically be caught by 
@preserved-rebuild or revdep-rebuild.  Was I incorrect?

> Yep. I thought of it as an opt-in symlink in case dmd isn't
> installed, so it could be emulated with gdmd or ldmd2.
> /bin/dmd -> /usr/bin/dmd might also be an option for that...
> Nah, I'll see what might be required by some tools.

I wonder at what point a d.eclass needs to be made to negotiate 
all of this; I'm really not sure.  On that note, you may want to 
watch out for degenerate cases like packages trying to select a 
preferred compiler, just in case.

-Wyatt