Working snap package definition for LDC

Wed Sep 7 11:19:03 PDT 2016

On Monday, 5 September 2016 at 08:03:05 UTC, David Nadlinger 
wrote:
> Thanks for doing this, and for keeping us posted!

You're welcome.  Thanks for all the help along the way :-)

> Pardon my ignorance, but it seems like having to include GCC 
> makes this currently an inferior way of distributing LDC rather 
> than just publishing .debs? How large are the binaries?

This is a good question, as it reflects a lot of concerns people 
have around snap packaging.  There's a short technical answer and 
a longer "big picture" one.

The short technical answer is that it isn't inherently necessary 
to include GCC in the LDC snap; it could be provided by another 
snap, which would expose an interface to GCC.  However, since no 
such interface currently exists, including GCC is a convenient 
way to get the LDC snap working now.  (It also has the advantage 
that it provides an entirely self-contained working system, 
independent of the system it's installed on.)

Interfaces are a slightly more generalized version of deb-style 
dependencies, via which snap packages expose particular pieces of 
functionality, which could be applications, libraries, hardware 
services, or just files.  The current list is fairly biased in 
favour of phone/tablet requirements:
http://snapcraft.io/docs/reference/interfaces

... so while developer-tool interfaces are planned, they're not 
yet available.  The impression I had was that the people 
concerned are taking some time to think carefully about what the 
best way is to do this; one option would be to define an 
interface that just exposes the developer toolchain of the 
underlying system.

By the way, that touches on a much more serious limitation of the 
current snap package: because its containerization forbids it 
from accessing the host system, its linker won't be able to 
access system libraries outside the snap itself.  Probably 
there's a workaround, but the upshot is that if you do,

     ldc2 -of whatever whatever.d -lsomelibrary

... you'll get a linker failure.  Because of this I'm not pushing 
the snap to the Ubuntu store for the time being.

An interface that exposes the developer resources of the 
underlying system would solve that, and there are probably other 
alternatives; from what I understand it's work in progress.

To the bigger question of snap package design: essentially the 
use case is different from deb packaging.  Broadly, I would say 
that it's about giving software creators a format via which they 
can guarantee that their software will work with minimal 
assumptions about the host system.  A lot of this relates to 
concerns about IoT, smart devices, etc.: if you think about a 
phone, or a router, very often in practice the hardware 
manufacturer can form a bottleneck, if they don't take 
responsibility for updating the device OS.  By contrast the kind 
of system that Ubuntu are trying to build (as seen with e.g. 
their phone and tablet offerings) is one where the hardware 
manufacturer only really needs to care about the 
hardware-compatibility software layer, which they should be able 
to update largely independently of the rest of the software 
stack; similarly the OS provider is able to independently push 
out updates for the OS core, app providers are able to 
independently push out app updates, etc. etc.

What that probably means, though, is that where deb packages are 
largely designed with the goal of supporting a well-curated and 
well-integrated distro where the individual pieces are as cleanly 
separated as possible, snap packages are perhaps more oriented to 
providing well-curated smaller collections of software (e.g. the 
KDE core libraries, or a minimal KDE desktop) that don't need to 
assume the other software on the system has been curated with 
them in mind.

All of this, of course, is filtered through my own understanding, 
so more advanced questions may be better directed to the 
snapcraft mailing list:
https://lists.ubuntu.com/mailman/listinfo/snapcraft

The final word I'll say is that, despite the niggles I 
encountered, I was very struck by how extraordinary easy it was 
to get up and running with snap packaging, and how readily those 
issues had simple solutions that involved minimal change to what 
I'd already done.  For that alone, I'd see it as quite an 
exciting development.

Anyway, I'll keep you posted further as things progress ;-)

All the best,

     -- Joe