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