Top-level package names, UX questions

[Alexander Sack]

On Mon, Mar 16, 2015 at 7:02 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
> On 16/03/15 08:22, Michael Vogt wrote:
>> 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
>
> The package.developer namespace allows us to have many versions of the
> same package from different developers installed at the same time.
>
> This will almost certainly not work for frameworks, however, which are
> typically mediating a shared resource between apps.
>
> So, if we can't guarantee that you can always have package.dev-a and
> package.dev-b co-installed, perhaps it would be better not to allow that
> altogether? If we said you can ONLY have one version of "package"
> installed on a system at a time, lots of things get easier ("it's always
> just apache.command") and some things get harder ("you can't have both
> the mainline and a sideline version installed at the same time").
>
> I'm leaning towards saying that developer versions would conflict with
> mainline versions - for a device, pick one or the other. I can't
> recalled why we went the other way, now, in prior discussions. Could
> someone remind me of the rationale, or make the case from first
> principles, for having both "apache" and "apache.beuno" installed on the
> same device at the same time?

I tried to figure what we really wanted here as well last week and
couldn't get a clear answer.

I think our initial intend was really to have the semantic of
.developer being like a special lane of the same thing, so you can
basically switch from mainline to developer1 to developer2 and you can
only have one installed at same time. This would also avoid the super
nasty cli names like vim.editor.beuno.

Then we deferred the real toplevel namespaces and I think we mixed up
name/trademark resolution with this topic, so we felt that bash.beuno
is valid to be coinstalled with bash.asac as bash might be two
entirely different things that are not even the same software.

I tend to think we should stick to the original idea and say "only one
of apache, apache.beuno, apache.mvo" can be active at any time. Same
true for apps as for frameworks. In this way you can snappy switch to
the developer variant or the sideloaded one or the one that you have
local with your path.

I know there are technical implementation challenges for that around
store etc., but I think we should make those dominate the semantic and
experience we want and that experience just shouldnt have a
editor.vim.beuno command :) - but let me finish reading this thread

>
> Mark
>
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel