Top-level package names, UX questions

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Tue Feb 24 15:02:05 UTC 2015


With juju we used an alias to the fully defined namespace, and it
works pretty well.

As a side note, the convention of <package name>.<user> feels somewhat
unfortunate. I'm not sure if there's still time to tweak it or if you
are married with the concept to a deep level already. If possible, I
would try to design a convention that is slightly harder to obtain
ambiguous interpretation from. As example based on the few mentions in
your text, consider the effect of having a user named "start".



On Mon, Feb 23, 2015 at 3:43 PM, Martin Albisetti
<martin.albisetti at canonical.com> wrote:
> Hi all!
>
> We've kicked off the work to support top-level package names (eg
> "apache" instead of "apache.beuno"), and plan to work on it in a few
> iterations, each adding a bit of usefulness each time.
> You may have seen there are already some apps that have this
> ("docker", "hello-world"), but those were implemented in a bit of a
> rush to release and only work for Canonical applications. We would
> like to open this up this option a bit more.
> We care about keep the ecosystem safe and pleasant, so we'll ask that
> top-level package names are reviewed manually the first time they are
> requested. The final plan is for apps to be uploaded to the store
> under their developer namespace (like PPAs work in Ubuntu today, to
> some extent) and have those get established in the community as the
> way to access that particular piece of software, and then essentially
> graduate to a top-level name. More on that in the future, for now
> we'll keep things nimble and just leave them flagged for manual review
> the first time you upload.
>
> Given how we see the path currently, it means packages will
> essentially have, at least from the Store's point-of-view, both
> namespaces equally accessible ("apache" and "apache.beuno").
> In this first pass at the implementation, the quickest iteration to
> allow proper usage is to not support transitions, but rather start by
> supporting new packages that will use the top-level namespace from the
> start.
> 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
>
> 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
>
> We had an internal discussion about this already, but didn't land on
> any conclusions so I'm trying to summarise the discussion and the
> problem well enough for a wider audience.
>
> Option 1 is tempting, since it effectively allows package name
> transitions with no need to change the packages themselves, but for
> sideloading it's a bit awkwards as you have to provide both a package
> and a piece of metadata separately.
>
> 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".
>
> I don't have an opinion on the exact implementation on the client, I'm
> happy for the store to provide the extra metadata payload separately,
> however much amount of it and for it to parse any value out of the
> manifest file.
>
> I do care that we support the path from a developer namespace to a
> top-level namespace in a seamless way for the user (ie. they don't
> need to know about it at all).
>
> Thoughts?
>
> --
> Martin
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel



-- 
gustavo @ http://niemeyer.net



More information about the snappy-devel mailing list