On 28/08/16 08:00, Joseph Rushton Wakeling wrote: > >> We would like to add the ability to have a single snap offer up multiple >> base-level commands. This will require some changes to snapd, if you are >> comfortable writing code in Go then feel free to take this on as a >> challenge :) Niemeyer or MVO on IRC would be able to give you some >> implementation strategy ideas. > > Well, no promises (busy times elsewhere in life), but I'll certainly > try to take a glance. I've never written go code before, but there's > a first time for everything... >
Can highly recommend learning Go, but this would be the deep end, better to find more straightforward starting point :) >> For now, if you have a command with the same name as your snap, then >> that one can drop the namespacing. So if your one command was "ldc" then >> you would not need ldc.ldc you could have just ldc. > > Cool, thanks! I'll rename the snap to `ldc2` then (this is the > expected compiler command). > > That still leaves `ldmd2` to deal with later, but that's less > important in general. Yeah, that would end up as ldc2.ldmd2 for the moment, but once we have multiple commands mapped in from the snap we could allocate the ldmd2 command to it and it would automatically become available without the snap namespace prefix. > I presume a complication here is that a snap package might be > installed into /snap/ or into /home/<user>/snap/ so the precise path > would have to be determined at install time, it can't be known at > packaging time ... ? > > Is there any wildcard that could be used in order to get the snap's > install dir, that could be inserted into the config file? Along the > lines of, > > -I$WHERE_THE_SNAP_LIVES/include/d/ldc > Try $SNAP for the location of the snap root, and there are a few others like $SNAP_DATA and $SNAP_COMMON and $SNAP_USER_DATA and $SNAP_USER_COMMON which are writable directories (the COMMON ones are unversioned the others get snapshotted on update). The snap also get its own /tmp directory. > Re the classic system -- it did occur to me that the most > straightforward short-term solution would be to require that the > `classic` snap be present. So in that case it's just a matter of > exposing (say) a `gcc` interface from the classic snap, or just the > linker if it's possible to be narrower? Yes you can arrange for the snap to see stuff from the rest of the world, but the more of that you have, the more you burden the user to get all those bits in place. I would explore the bundling option and see how that pans out. It doesn't look like it's particularly large. And we're adding delta updates so even if it is quite large it will only affect update sizes when it changes. > Is this the point where we start singing, "I want you, I need you" to > one another? :-P LOL :) Mark -- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
