Thoughts about D package management on Gentoo

[Dicebot]

On Saturday, 9 November 2013 at 13:23:33 UTC, Marco Leise wrote:
> Yeah, I was pointing at the lock-step upgrade nature of D
> development. You can't really update one without the other
> when it comes to every day package management.

True. This why I have them all in a single PKGBUILD (ebuild 
analog I guess) despite those looking separate in package manager.

>> > - Tools tend to expect that "dmd" is available as a command.
>> 
>> Actually I don't think this is true for newer ones. There are 
>> plenty that tend to either use `rdmd` or detect compiler 
>> present in the system.
>
> Good, the only thing that might go wrong then is alternate
> binary names or install locations.

Well the idea is simple - whatever install locations are, 
packager provides default /etc/dmd.conf (ldc has similar conf 
file and gdc needs to be patched during build) that allow plain 
compiler invocations to "just work" without figuring out any 
actual path. I also have common base path for all D modules 
installed via `pacman` - "/usr/include/dlang/" which is in 
default `-I` list so that any library installed that way can be 
directly imported with no extra steps.

> Your experience is welcome! Does D1 have a place in that
> model?

AFAIK no one uses D1 but company I am working for :P

> And what does really happen when you work with e.g.
> dmd-2.065 and found a D application in the tree that hasn't
> been updated for a few weeks, so it still requires 2.064?

It is somewhat easier in Arch case as core repositories provide 
pre-compiled binary packages. So it does not really matter what 
compiler version is required for application if it is statically 
linked and is not a library on its own. For source-based packaged 
(AUR in Arch case) I'd send a pull request upstream :) Or mark it 
out-of-date and wait :)

> It would more or less mean that the whole D package system
> would have to be updated in one go, when all packages are
> updated to the latest D version, which can take a while.

It is pretty much what happens right now anyway as it is defined 
by nature of D versioning / releases and there is not much we can 
do about it :)

>> > Next a symlink should be established to the current
>> > implementation of dmd, e.g.: /bin/dmd -> /bin/ldmd2.
>> > This symlink could be managed with an eselect plugin as it is
>> > already done for other languages like Python or the Java
>> > Runtime.
>> 
>> And what if one wants to have all 3 simultaneously?
>
> You call them by their real names. :)

Well, "dmd" IS real name for dmd ;) In that sense that "dc" 
proposal makes much more sense.