Thoughts about D package management on Gentoo

[Marco Leise]

Am Mon, 11 Nov 2013 15:43:11 +0100
schrieb "Wyatt" <wyatt.epp at gmail.com>:

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

The versions in the sunrise overlay are already slotted for
D1/D2. The D1 dmd is renamed to dmd1 there. While I'm not
planning to rename dmd to dmd2, I took the concept a level
further and slotted for _every_ D version (except patch
levels). At least the current version of D1 cannot become
outdated any more. It's paradox I know. ;)
 
> 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.

Positive on that one. I install dmd1.076 and dmd2.064 and have
"eselect dlang set --dmd dmd1.076" set the dmd symlink to D1.

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

Gentoo will keep the previous .so and the application
will continue to work, that is correct. But a clean state is
only reached when the application is rebuild for the new
version of the library using @preserved-rebuild and the
old .so is removed. And that's where Phobos might have a
changed API and the application wont compile any more.
It doesn't happen often I think, but there is also no
guarantee, no version number indicating a fixed API. And as
long as there are things like "shared" and allocators still to
iron out, I can live with that situation.

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

That was amongst the first things I had to write ^^. In a
separate overlay it doesn't really matter how many of them you
have. As long as it shortens ebuilds, I'm all for it. GCC
really works that way, too. The ebuild is surprisingly short.

> On that note, you may want to 
> watch out for degenerate cases like packages trying to select a 
> preferred compiler, just in case.

That's the fun of ebuild writing. Apart from the compiler I
also need to pass compiler and version down to any
dependencies. And I saw no other way but doing that through
USE flags. If that system works out, it will be annoying as
hell. You might already have installed GtkD for gdc, dmd and
ldc in 3 different language versions = 9x and then comes a new
dependency that requests a 10-th version so you have to wait
through 10 compiles of GtkD again.
The only way to independently install a package multiple times
is through slots, and I want to keep that option for what it is
intended. Multiple API versions of the library in question.

> -Wyatt

-- 
Marco