Top-level package names, UX questions

Martin Albisetti martin.albisetti at
Mon Mar 16 18:52:30 UTC 2015

On Mon, Mar 16, 2015 at 12:22 PM, Michael Vogt <mvo at> wrote:
>> With all that context in mind, I'd like to get some feedback on where
>> and how to specify the package namespace.
>> As I see it, we have 3 options:
>> 1) It's not specified at all in the manifest file in the package, the
>> metadata for that is provided separately by the store all together
>> 2) The package's manifest always contains the developer's package
>> namespace (apache.beuno), and the store provides the metadata
>> separately
>> 3) The package's manifest contains the top-level namespace
> 4) We also have the option that the package name in the
> meta/package.yaml is the name in the store. So either "apache.beuno"
> or "apache". That of course means that in order for a package to
> become a top-level namespace package it needs to be re-uploaded once
> with the new name "apache" and there is no automatic transition
> (we could provide automatic transition via a simple alias in the
> store, but to me it feels odd when a package apache.beuno suddenly
> changes the on-disk name and possible the command name).

Right. I think we need to make sure both commands continue to work.

>> The pieces affected by this decision are:
>> a) Path on disk (/apps/packagename)
>> b) How to execute binaries in the package (apache.start)
>> c) What the developer specifies (or has to remember to specify!) in the manifest
> [..]
>> Options 2 and 3 are similar enough, that I think it mostly comes down
>> to how it affects the pieces identified before. I wouldn't want you to
>> have been running "apache.beuno.start" for a year, and then suddenly
>> with an update it stops working because it gets upgraded to
>> "apache.start".
> What I dislike about 2+3 is that the location on the filesystem and
> the commands depends on data from outside the snap. I.e. if you
> re-pack /apps/apache and install it on a different system it may end
> up as /apps/apache.beuno there because some store meta-data is
> missing (not a big deal, but it feels cleaner if the snap is
> self-contained to me).
> What I like about option (4) is that its simple and predictable. You
> install apache.beuno and its /apps/apache.beuno/$version. You install
> "apache" and its /apps/apache/$version. The binary names stay the same
> etc.  It also makes side-loading easier, all meta-data is in the
> package name.

Agreed that's valuable.

> We could provide some info feature for the transition, i.e. if
> apache.beuno becomes apache we could show a message on update that the
> package got a new name.

I fear though, you then rely on someone's memory or that they were the
ones to see that when it was displayed, especially in
everything-is-always-automatically-up-to-date mode.


More information about the snappy-devel mailing list