|Posted by Joseph Rushton Wakeling|
in reply to David Nadlinger
Posted in reply to David Nadlinger
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:
... 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:
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,