Top-level package names, UX questions

[Martin Albisetti]

On Mon, Mar 16, 2015 at 3: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.

Agreed. I think this flags something unaccounted for, which is that
frameworks likely should be restricted to using flat namespaces.


> 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").

Indeed they do get easier. I think, though, it comes at the expense of
being heavy-handed with how the ecosystem grows. There's a lot of
first-come-first-serve for popular names, and makes it more common for
renaming to have to happen down the like as competing apache's
improve.


> 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.

We can have both "apache" and "apache.beuno" co-installed, if we
choose wisely how to implement this.
There are 2 separate cases here, that we might be conflating.

1) "apache.beuno" exists, but is my take on apache, which might just
be popular with a small, lets say exotic crowd
2) "apache.slangasek", which turns out to be stable and popular, and
is promoted to "apache"

How "apache.beuno" and "apache" co-exist, I think, is clear and
understood. The key question is how we handle the transition from
"apache.slangasek" -> "apache" for folks who already have
"apache.slangasek" installed, because it was popular in the first
place.
If the package manifest is changed from "apache.slangasek" -> "apache"
when the "promotion" is approved, the question remains on how to
handle that on disk. Do we rename it? Do we leave it alone?
If it isn't changed, how do we make sure the system knows about this
promotion, allowing you to now access the package with the new, more
convenient name?  A second entry in the manifest?  A separate piece of
metadata from the store?
Regardless of what we do, we need to make sure we don't break
anybody's existing installation, so the package needs to continue to
be accessed from its previous namespace, as well as the new one.

We could also say that you essentially have to upload a new package,
that will have existed from the beginning as "apache", but you would
loose your existing community of users, which is not ideal for either
party.
Another option would be to leave you alone, and you remain unaware
that it's now called "apache" as well, and only new installs get
"apache". I fear that might confuse people too much, though.


> 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?

Given developers upload directly to the store, with no mediation, we
can't easily guarantee that apache.beuno is the apache webserver and
not a native-american history app, or that while of similar quality to
"apache" mine has some experimental but incompatible changes to it,
that some folks use for some things while using the known-stable
"apache" for others.
Overall, it lets the ecosystem grow without heavy intervention and
allows for a lot of experimentation that doesn't pollute anything
else.

After digesting it, my feeling is that the smoothest approach would be
for the manifest file to carry both namespaces, and that covers all
use cases. New installs can just be called "apache", old installs can
remain untouched "apache.slangasek", and both new and existing users
can access the app using both namespaces.
No matter what avenue we go down, I particularly care about
"apache.slangasek" to continue to work after the promotion to "apache"
to ensure that all the blog posts out there pointing to how to install
this package don't suddenly break.

-- 
Martin