Practical Problems with distribution D projects

[Assaf Gordon]

On 02/25/2014 10:06 AM, Dicebot wrote:
> On Tuesday, 25 February 2014 at 14:51:48 UTC, Assaf Gordon wrote:
>> My target audience is not D developers - it is unix casual users
>> (not even developers). I want to make it the easiest for them to
>> use my program. If it's requires more than the standard "configure
>> && make && make install" (or the cmake equivalent), then many of
>> them will not do it.
>
> Then push it into distro repositories. You are NOT helping by
> recommending them to do "make install", quite the contrary, harming
> whole ecosystem. Casual users should not be even aware that "make
> install" exists. Being one of package maintainers myself I really
> hate this kind of "helping" attitude, it causes only trouble.

I'm sorry it makes you upset - I can see how frustrating it is for a package maintainer.

But I think "harming the ecosystem" is a bit of a hyperbole - in an ideal world where Linux Distros contain every piece of software (and up to date version), there is indeed very little need to install from source.

But there are several real-world constraints, at least in the environment I work in:

1. Software needs to run on variety of servers and distributions, some are very old (e.g. CentOS 5.4 or Ubuntu 10.04).
Upgrading is not an option for these environments.

2. Software needs to be installed without root - to a user directory (i.e. using "configure --prefix" or similar).

3. Software is updated too frequently, or is too new, or (sadly) too experimental (code-wise) for inclusion in a stable distribution package - but it still needs to be used.

4. It takes time for a software to be properly packaged, and users want to install it now. Also - it will not be available in the "stable" branch of the distribution.

In addition, some distribution have extra requirements.
For example, Debian frowns upon compiling with static libraries when a shared one is available.

If there is already a package in official Debian which is written in D, it would be very helpful to see an example of the packaging process.

>>> Single Linux-wide binary distribution is mostly a myth and dmd
>>> shows it by its own.
>>
>> Not sure what the "myth" is - but a statically-linked binaries work
>> well (if your program is self-contained and properly compiled), and
>> there are many examples of it.
>
> Except you never have truly statically linked binaries, there is
> always at least glibc.

I'm not sure I understand this statement.
If I link with "gcc -static" and my program is properly built, the resulting binary does not require any library, not even glibc.
It uses only Linux ABI syscalls.
Unless I'm mistaken?

>
> Please stop distributing software for Linux with Windows attitude.

Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...

My first choice would be to have a project in D which is easily compilable from source code.
Either with "make" or "dub" or "configure" or anything else.
Once I have that, packaging (for a linux distribution) is straight forward, and so is adding it to HomeBrew/LinuxBrew.

At the moment, I don't think it's possible (in the level of "easiness" comparable with C/autotools-based projects).

The alternative (for linux) is distributing a binary program, and for that, a static-binary is much more portable than a dynamic one.

Having GDC and LDC in Debian is an excellent start - I was not aware of them, and it is certainly the right direction.
But those are still not available in the "stable" branches, and so, not easily usable.
In the future this will definitely change.

-Gordon