On Monday, 12 August 2013 at 10:38:21 UTC, Russel Winder wrote:

>
> Anecdotal experience indicates this musn't be an "or" situation.

Perhaps. My response in this thread derived from a brief exchange Jonathan and I had over at github. In packaging Derelict for Fedora, he had been relying on a pull request I accepted from him some time ago that added shared library support to the Derelict build script. I decided to remove it as it has fallen out of sync with the static builds now and again and it was only there for his use. At any rate, as part of my plans to restructure the project, I'm going to drop the build script and rely on dub exclusively. From his post here coming so soon after our exchange, I get the impression that I may not be the only one he's heard that from.

As long as packaging the various distros doesn't require any constraints on how I manage my projects, then it doesn't matter too much to me where or how people package it up. However, I do see benefits to promoting dub as the means to build up the D ecosystem. Then it's a central, goto location for D libraries and everybody's on the same page. As long as dmd/gdc/ldc and dub are available via the distro packages, that's all that really matters

On Monday, 12 August 2013 at 13:06:46 UTC, Mike Parker wrote:
> As long as packaging the various distros doesn't require any constraints on how I manage my projects, then it doesn't matter too much to me where or how people package it up. However, I do see benefits to promoting dub as the means to build up the D ecosystem. Then it's a central, goto location for D libraries and everybody's on the same page. As long as dmd/gdc/ldc and dub are available via the distro packages, that's all that really matters

From the point of view of packager I'd say there are 2 key issues here:

1) Developers tend to forget that tools like `dub` are for taking care of dependencies during development and end users won't have `dub`. Even if it is a library, dynamic linking implies that it will be pulled as a dependency not only by developers. That may result in complications for integrating package into existing package system. Sometimes.

2) `dub` is still quite immature when it comes to target path configuration (unless I have missed some changes) - converting its build output to FHS is not always convenient.

In my opinion, though, those are mostly quality of implementation issues, nothing fundamental. Can't say how much troubles does this really cause right now, have not tried to package anything like Derelict yet.

> I don't know how it is for other distros, but the newest dmd and ldc version are available in the Archlinux's [community] repository while gdc and dub are available in the AUR, meaning you get a fully working D environment on Archlinux by doing

LDC is in [community] already, and iirc Dicebot is working on getting GDC into [community], too

On Monday, 12 August 2013 at 13:46:52 UTC, David wrote:
> LDC is in [community] already, and iirc Dicebot is working on getting
> GDC into [community], too

Actually I am simply waiting until my PGP key gets signed by at least 3 Arch Linux master keys :) Will make announcement about all package changes and yummies once done.

On Monday, 12 August 2013 at 13:06:46 UTC, Mike Parker wrote:
> In packaging Derelict for Fedora, he had been relying on a pull request I accepted from him some time ago that added shared library support to the Derelict build script.

Jonathan unfortunately has also opted to build druntime and Phobos as shared libraries in the LDC Fedora package, even if that is known to produce random segfaults due to the interaction with TLS not being properly handled yet (stay tuned for an new release early September including 2.063 and hopefully proper .so support on Linux). This might effectively be worse than having no D compiler package in the official repositories at all, as it is prone to give a false impression regarding the stability of D.

In part, this might have been partly our (or more specifically, my) fault for not clearly labeling the respective experimental CMake option as such and not explicitly pointing out the fact that shared libraries don't work out of the box without special hacks when asked about the possibility. And if I remember correctly, the Fedora packaging guidelines also pretty much prohibit distributing static libraries if it can be avoided at all (D is such a case, though, or has at least been until very recently).

In general, I think this situation highlights how important close collaboration and proper communication between upstream developers and packagers is. Sure, one could argue that the main project developers should also try to handle packaging for the most common target platforms, as it is also essential if the application is supposed to ever gain traction on systems where a package manager is used pervasively. However, in reality, we are all doing this in our spare time, and even if you restrict yourself to, say, Debian, Fedora, MacPorts and Homebrew, this probably means that you have to familiarize yourself with at least 3 systems you don't use on a daily basis before you can even think about creating packages for them.

Maintaining packages for your favorite system is a low-effort/high-impact way to help with D development; I really wish more users would consider lending a hand here.

David

On Monday, 12 August 2013 at 13:38:11 UTC, Dicebot wrote:

>
> 1) Developers tend to forget that tools like `dub` are for taking care of dependencies during development and end users won't have `dub`. Even if it is a library, dynamic linking implies that it will be pulled as a dependency not only by developers. That may result in complications for integrating package into existing package system. Sometimes.

That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm.

On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote:
> That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm.

Yeah, but imagine creating hard dependency on certain library version in sources (with no real need, something like too specific SONAME) - it requires package maintainer not only to keep bundling script, but also to patch project sources before building. Something maintainers are usually not happy to do :)

It is not that common but forgetting that user environment will be different from yours is kind of easier with all the convenience `dub` brings you.

In general I think keeping packager and developer duties separate is a good/right thing, however, it is much easier when developers think about binary dependencies separately from source ones.

On Monday, 12 August 2013 at 15:39:59 UTC, Dicebot wrote:
> On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote:
>> That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm.
>
> Yeah, but imagine creating hard dependency on certain library version in sources (with no real need, something like too specific SONAME) - it requires package maintainer not only to keep bundling script, but also to patch project sources before building. Something maintainers are usually not happy to do :)
>
> It is not that common but forgetting that user environment will be different from yours is kind of easier with all the convenience `dub` brings you.
>
> In general I think keeping packager and developer duties separate is a good/right thing, however, it is much easier when developers think about binary dependencies separately from source ones.

My view may indeed be heavily tinted by Windows, where this sort of thing just isn't an issue to care about. I suppose I'll have to adjust that a bit.

On Monday, 12 August 2013 at 15:55:10 UTC, Mike Parker wrote:
> My view may indeed be heavily tinted by Windows, where this sort of thing just isn't an issue to care about. I suppose I'll have to adjust that a bit.

Hah, yeah, I guess the very understanding of user-distributed "package" is very different between various OS users. As far as I remember, it was considered a normal practice to pack all used shared libraries with programs installation in Windows (ignoring "shared" part) - something that is allowed in Linux repository packages only in absolutely exceptional cases. And Mac OS is somewhere in between.

On 2013-08-12 12:38, Russel Winder wrote:

> Currently GDC is in Debian, but I have to get DMD from a private Debian
> repository instead of the official one, and I build LDC myself because
> the Debian package is too old. This measn having to have three versions
> of all the libraries and packages because each compiler requires it's
> own. This sort of situation is well supported via platform packaging and
> currently seems unsupported completely via D-specific things – but I may
> be missing something.

DVM installs each compiler in its own directory. Although you have to manually put libraries and imports in the correct directories. It also currently only supports DMD.

-- 
/Jacob Carlborg