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.
