Official package maintainers for dfmt, dscanner, dcd

[wilzbach]

Based on this NG question I think it's worth exploring whether we can help to simplify the installation process of our maintained tools. This thread is about exploring Linux distros and homebrew (there's another one about creating bundled releases).

I guess the main questions are:

• What is the current status?
• What can be done to improve it?

Current status

I found the following packages:

AUR	dfmt, dfmt-git, dfix, dfix-git, dcd (community), dcd-git, dscanner, dscanner-git
Homebrew	dfmt, DCD, Dscanner, Dfix
D-APT	available as packages

What can be done to improve it

As these tools have been moved to the dlang-community quite recently, helping directly at upstream should be a lot easier.

CC @ximion as he was a great help in getting tilix into Debian
CC @JohnColvin as I think the existing packages on homebrew need at least an URL update (e.g http://brewformulas.org/Dfmt)
CC @foutrelis as he seems to be maintaining the dcd for Arch Linux
CC @Vild as he seems to be maintaining all the AUR packages

[JohnColvin]

I think you've pinged the wrong person. I don't know D, so I'm not gonna be much help 😄

[ghost]

@John-Colvin; the one related to D

[John-Colvin]

Shouldn't be any need for immediate changes in homebrew (github automatically redirects). Will update to new URL on next release.

[ximion]

As far as Debian is concerned, we need the following things that could be a problem specifically for the projects mentioned:

• We do not allow bundled 3rd-party code (I see a lot of Git submodules), so ideally we would need to unbundle these libraries so we have just one copy of a specific bit of code in the archive.
• Using dub for Debian packaging does not work at all at the moment due to dub bugs (unless the project has zero dependencies on other code, then using dub is okay-ish). So you'll need either a Makefile/CMake/Automake/Meson build definition. A lot of projects seem to have makefiles.
• In order to pass QA, manpages for binaries in default $PATH (/usr/bin, /bin, /usr/sbin, ...) are very helpful.
• At least at the moment the projects need to work with LDC or GDC. We will need some compiler peace treaty for the Debian archive once DMD is available there as well, to ensure we have a somewhat coherent D ecosystem in the archive (and not a lot of components that can only be used with a specific compiler). At the moment, the preference is on LDC for it's better optimizations and larger amount of supported architectures and still recent DMDFE version. A stable ABI or at least compatible ABI between D compilers using the same frontend would solve these issues, but unfortunately it doesn't look like this will happen anytime soon. I am still looking into how to resolve this issue in a way that doesn't make D package maintenance a pain (will likely involve shipping source code for libraries instead of binaries).

The most important thing we need is maintainers for the Debian packages and people willing to support them for the upcoming releases.
We have a generic upstream guide for how to make projects Debian-friendly and easy to package and ship. See https://wiki.debian.org/UpstreamGuide for more information.

If you are interested in helping, please join the Debian D Team - I would be willing to sponsor packages in case someone is no DD, however I don't think I have time to teach anyone proper packaging, so you should ideally have some experience with that (I'll obviously review and comment on the packages).
Cheers,
Matthias

[rikkimax]

@Hackerpilot extension of this is the post: http://forum.dlang.org/post/hsunymjmytwsgnjjrlkb@forum.dlang.org
Any blockers for distributing them together for e.g. Windows?

[Hackerpilot]

I'm not opposed to it happening, but I'm too lazy to do the work myself.