ubuntu-appstore-developers team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 07/10/2013 09:35 AM, Ted Gould wrote:
> On Tue, 2013-07-09 at 22:19 -0500, Jamie Strandboge wrote:
>> On 07/09/2013 09:47 PM, Ted Gould wrote:
>> > I was chatting with some folks about Click packages and the idea of having
>> > multiple entry points for the user for the application.  In legacy application
>> > terms this would be having the Click package install multiple desktop files. 
>> > Should this be possible?  Is it a requirement to have it?
>> > 
>> > I think that this creates an odd user experience.  You're sitting on the
>> > application lens, you see an application there which you click on and install,
>> > then it morphs into two icons.  Seems a bit odd to me.
>> > 
>> > I think that the counter-argument is that there might be closely related
>> > applications where a single bundle makes sense.  For instance Facebook main
>> > application and Facebook Messenger.  While I understand this, I don't think it's
>> > compelling over the oddity of the first case.
>> > 
>> > What are other people thinking here?
>> > 
>>
>> I think it is perfectly reasonable to say in the beginning that only one desktop
>> file is allowed as a matter of Ubuntu policy-- especially if it simplifies the
>> early implementation. I don't think the lowlevel tools themselves should
>> artificially be limited by this policy though-- ie, there is no reason why click
>> itself can't support multiple desktop files in a package, or that the security
>> manifest can't specify multiple apparmor profiles. I think it is hard to predict
>> what will be useful for application developers at this time, so we've
>> implemented the tool for handling the security manifest such that it can have an
>> arbitrary number of apparmor profiles. This way a higher level lint tool can
>> easily limit it to one now without painting us into a corner down the line.
> 
> This unfortunately isn't just limited to things like Click packaging and the
> tools around it.
> 
> For instance Mir requires the application to register with the display server
> and who it is.  This is the application ID.  Previously I had thought that would
> be synonymous with the Click package name "com.ubuntu.camera" but if there are
> multiple desktop files it needs to take that into account as well.  So it'd have
> to be something like "$(clickpage).$(desktopname)" or "com.ubuntu.camera.camera"
> and "com.ubuntu.camera.camcorder" to use Marc's example.
> 
> So I think that we do need a decision, and we need it to be fairly universal so
> that all the teams working in similar areas can make sure to integrate when the
> time comes :-)
> 
I thought we solved this in the other thread. See the wiki[1]: for each unique
profile name in the click manifest, there is an apparmor profile. Each profile
name in the manifest corresponds to the desktop file. We then generate apparmor
profile names based on $name_$desktopfile_$version, where 'name' and 'version'
come from the toplevel manifest and 'desktopfile' is a key from the profiles
dictionary. Eg, the apparmor profile names and filenames on disk are:
 * com.ubuntu.developer.username.myapp_myapp.desktop_0.1
 * com.ubuntu.developer.username.myapp_myapp-camera.desktop_0.1

You take the same approach that my team did and use the name, version and list
of desktop files (ie, keys to the profiles dictionary) to generate your APP_IDs.

[1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click


-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature