On Mon, Feb 23, 2015 at 04:43:14PM -0200, Martin Albisetti wrote: > Hi all! Hi Martin,
> 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. Great, thanks a lot! [..] > 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). > 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. 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. Cheers, Michael -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
