www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Working snap package definition for LDC

reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
Hello all,

Thanks to everyone's help here, and similar great help on the 
snapcraft mailing list, I now have a working snap-package 
definition for LDC.  The PR to finalize it is available here:
https://github.com/WebDrake/ldc2.snap/pull/1

Obviously I can just push this out to the world, but I'd like to 
give everyone here an opportunity to review this before I 
finalize things.

Thanks & best wishes,

     -- Joe
Sep 04 2016
parent reply David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc puremagic.com> writes:
Hi Joe,

Thanks for doing this, and for keeping us posted!

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?

  — David


On 4 Sep 2016, at 12:53, Joseph Rushton Wakeling via digitalmars-d-ldc 
wrote:

 Hello all,

 Thanks to everyone's help here, and similar great help on the 
 snapcraft mailing list, I now have a working snap-package definition 
 for LDC.  The PR to finalize it is available here:
 https://github.com/WebDrake/ldc2.snap/pull/1

 Obviously I can just push this out to the world, but I'd like to give 
 everyone here an opportunity to review this before I finalize things.

 Thanks & best wishes,

     -- Joe
Sep 05 2016
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
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
Sep 07 2016