Thoughts about D package management on Gentoo

[Marco Leise]

Am Sat, 09 Nov 2013 12:21:30 +0100
schrieb "Dicebot" <public at dicebot.lv>:

> Some comments on general packaging topic.
> 
> On Saturday, 9 November 2013 at 00:38:16 UTC, Marco Leise wrote:
> > - Compiler and library are closely coupled and depend on each
> >   other.
> 
> Not really true, it is straightforward to write an alternative 
> druntime / stdlib substitution to use with existing compiler 
> package.

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.

> > - Each new D point release brings a new, generally
> >   incompatible standard library.
> > - All three major compiler backends are in good shape and use.
> >   But their generated code is not exchangeable (as far as
> >   I've heard due to ABI differences).
> 
> Yes, ABI is the key issue that makes 3 major compiler ecosystems 
> not interchangeable in any way. And it is not likely to be fixed 
> any time soon.
> 
> > - 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.

> > To deal with the complexity of package dependency management
> > in this scenario, we need to be able to install multiple
> > versions of D compilers in parallel (similar to what dvm does).
> > This can be accomplished by so called "slots" for each point
> > release. We can do this for all three compilers and will end
> > up with binaries like "dmd2.064" and "gdc2.063".
> 
> I have been thinking about it when doing Arch packaging but 
> discarded that approach as not KISS. All maintained applications 
> support either latest compiler version or previous one. Rare 
> cases when legacy version is needed are covered by dvm. In that 
> sense pure bleeding edge model suits D realities most and only 
> separation between dmd/ldc/gdc is needed.

Your experience is welcome! Does D1 have a place in that
model? 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 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.

> > 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. :)

-- 
Marco