Thoughts about D package management on Gentoo

[Marco Leise]

Am Sun, 10 Nov 2013 17:34:49 +0100
schrieb "Dicebot" <public at dicebot.lv>:

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

So a single PKGBUILD can advertise multiple items to install?
And when you later install more from the same package you just
run the PKGBUILD again and it reinstalls everything plus the
new options?

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

+1 I use this prefix now, too. Each compiler also has a
subdirectory there.

> > Your experience is welcome! Does D1 have a place in that
> > model?
> 
> AFAIK no one uses D1 but company I am working for :P

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.

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

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.

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

Well, we can keep "old copies" around till no one needs them
anymore. This is done for several other languages on Gentoo
and I have it working more or less for dmd now.

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

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.

-- 
Marco