Am Mon, 11 Nov 2013 15:43:11 +0100 schrieb "Wyatt" <wyatt....@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