Top-level package names, UX questions

[Alexander Sack]

On Tue, Feb 24, 2015 at 4:02 PM, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> 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".

We are not married to the current syntax/scheme, but we didn't come up
with something better. Any ideas?

>
>
>
> 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
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel