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

Didier Roche didrocks at
Mon Nov 14 09:27:00 UTC 2016

Le 13/11/2016 à 18:09, Joseph Rushton Wakeling a écrit :
> 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:
> OK, upstream accepted my patch to deal with this.  The current state
> of my external snap package, described here:
> ... now works with some essential basics:
>   * it can compile a program that has no dependencies;
>   * it can download dub packages from 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.

I guess for now, the compiler part (and access to system libraries)
should be part of an interface. I'm CCing Jamie to see if he has any
thoughts on that.


More information about the Snapcraft mailing list