Provisional snap for DUB (D language package/build manager)

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sun Nov 13 17:09:42 UTC 2016


On 13/11/16 10:11, Joseph Rushton Wakeling wrote:
> On 03/11/16 11:49, Joseph Rushton Wakeling wrote:
>> On 01/11/16 22:43, Sergio Schvezov wrote:
>>> If this is the problem and you can patch the software then removing the chown
>>> could work, I am CCing Jamie for other ideas that could come up.
>
> Looking at the dub source code, it seems that the actual build -- i.e. the
> compiler call that generates the binary -- writes to a temporary .dub/ directory
> created in the project tree, and the generated files are then copied to the
> user-perceived output location, with chown and chmod calls to preserve the
> permissions:
> https://github.com/dlang/dub/blob/v1.0.0/source/dub/internal/vibecompat/core/file.d#L126-L128

OK, upstream accepted my patch to deal with this.  The current state of my 
external snap package, described here:
https://github.com/WebDrake/dub.snap/pull/1

... now works with some essential basics:

   * it can compile a program that has no dependencies;

   * it can download dub packages from https://code.dlang.org/ and incorporate
     them into a project.

The major TODOs would be:

   * ensure the dub plugin downloads an upstream dub rather than relying on
     ubuntu packages;

   * separate the D compiler from the snap, allowing dub to use any compiler
     available on the host system (whether installed as a system package or
     as a snap package);

   * find a way for it to access system libraries so as to build dub packages
     that have these as dependencies.

The latter two I presume come down to the known issue about how to make host 
resources available to a snap in a safe manner, but I'd be interested in any 
thoughts on whether the D compiler issue might be achieved any more easily.




More information about the Snapcraft mailing list