Practical Problems with distribution D projects

[Dicebot]

On Tuesday, 25 February 2014 at 16:04:56 UTC, Assaf Gordon wrote:
> 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.

Apologise for overly harsh reaction, it is rather frequent source 
of frustration for me which makes reaction unacceptably nervous.

That "ideal" state is pretty much in your hands. There are as 
many packages in repos as people are willing to put - not like 
there is some important boss who decides what needs to be 
packages.

I know it is not very convenient with Debian because of how 
conservative it is but in Arch just asking in #archlinux @ 
freenode is likely to result in kind soul willing to help with 
packaging questions. Or even easier, just contacting me as it is 
my direct responsibility to maintain all D-related projects in 
Arch [community] ;)

As general rule of a thumb - if you application is useful, there 
always be someone willing to maintain package for it, assuming 
build process is not utterly insane.

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

I see, your requirements do not match use case of a typical 
desktop application. However, if you are fine with full static 
linking why not simply distribute binary tarballs for set of 
systems you want to support? It will put burden of having proper 
D compilation environment away from the end user.

It is worth noting though that for any normal application 
requiring package manager access (not full root) is expected and 
desired. Fast update issue can be solved by providing own 
upstream repository (i.e. launchpad)

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

Unfortunately all Debian/Ubuntu D packages I am aware about are 
found in non-official repo maintained by Jordi : 
http://d-apt.sourceforge.net/

Debian is probably hardest distro out there to deal with this 
kind of stuff.

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

I think it will work but I'd recommend to provide an option to 
build system to chose both dynamically and statically linked 
binary to simplify life for those who _may_ want to package it 
later.

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

I was referring to extremely common attempts to provide 
all-in-one "installers" ignoring normal practices of target 
systems that often happen when those used to Windows world start 
porting their stuff to Linux. And/or thinking about all distros 
as single target "Linux" system.

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

dub is the way to go in general, but it is not expected to be 
ever installed on user systems (well, unless it is Gentoo :)) - 
it is to be used by you or anyone willing to (re)package your 
application.

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

Within your requirements it may be a best choice. In general 
though I'd say that perfect portability is a flaw rather than 
merit. When speaking about desktop applications, for exampe, as a 
user of any operating systems I usually want software that is 
adapted to conform practices of this specific system and hardly 
appreciate how portable it is.