On Mon, Mar 16, 2015 at 12:22 PM, Michael Vogt <[email protected]> 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. -- Martin -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
