Guest User

xsacha bar files

a guest
Apr 26th, 2012
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 12.13 KB | None | 0 0
  1. Specialization of |Properties| and |Section| for BAR Manifest Files
  2. (:file:`META-INF/MANIFEST.MF`) and BlackBerry Resource Files
  3. (:file:`META-INF/{locale}.bbr`).
  5. The format of BAR Manifest Files and of BlackBerry Resource Files is
  6. specified in the |BAR| specification. The manifest contains meta-data
  7. describing the content of the BAR file; the BBR files contain
  8. localized versions of some of this meta-data.
  10. One design goal for this version of the code is that it be robust in
  11. the face of future |BAR| specifications. It accomplishes this largely
  12. by being as insensitive as possible to sections and attributes which
  13. it doesn't need to understand.
  15. One useful consequence of this design decision is that no separate
  16. implemetation is needed for BlackBerry Resource (BBR) Files, which are
  17. structurally identical to a manifest file (with the sole exception of
  18. the additional attribute :barattr:`Entry-Point-Localization`). As a
  19. result, although a BBR is only permitted in actuality to contain a
  20. subset of the attributes allowed in the full manifest, the same
  21. implementation serves for both.
  23. .. |BarSection| replace:: :class:``
  24. s���restructuredtext enu-���Neil Schellenberger <>uF���Copyright 2010, 2011, 2012, QNX Software Systems. All Rights Reserved.s���3.1.0t ���BarManifestt
  25. ���BarSectioniÿÿÿÿN(���t���BarAssetUnknownErrort���BarFileLimitErrort���BarPropertiesSyntaxErrort���BarPropertiesSemanticError(���t���Sectiont
  26. ���Propertiest���PropertiesError(���t���Digests(���t���asboolc�����������B���s5���e��Z�d��Z�d����Z�e�d������Z�e�d������Z�RS(���s ��
  27. A specialization of |Section| for |BAR| Manifest Files.
  29. Version 1.4 of the |BAR| specification states that a Manifest File
  30. may contain a variety of sections: 'Archive', 'Package',
  31. 'Application', 'Entry-Point', 'System', 'Debug-Token', 'Patch',
  32. and 'Archive-Asset'.
  34. The 'Archive' section contains mostly meta-data about the manifest
  35. itself.
  37. The 'Package' section contains attributes describing the BAR as a
  38. whole. The :barattr:`Package-Id` is guaranteed to be unique to
  39. this :barattr:`Package-Author-Id` and :barattr:`Package-Name`.
  41. The 'Patch' section appears only if the :barattr:`Package-Type` is
  42. ``patch``. It contains meta-information about the patch,
  43. including the effective package type,
  44. :barattr:`Patch-Package-Type`. The effective package type for
  45. non-patch packages is just the value of :barattr:`Package-Type`.
  47. The 'Application' section only appears if the effective package
  48. type is ``application``. The :barattr:`Application-Id` is
  49. guaranteed to be unique to this :barattr:`Package-Id`. An
  50. application may specify that it is to be installed in development
  51. mode (which has relaxed security), this is governed by the
  52. :barattr:`Application-Developer-Mode` attribute, which defaults to
  53. false.
  55. The 'System' section only appears if the effective package type is
  56. ``system``. It represents an operating system or radio package.
  58. The 'Debug-Token' section only appears if the
  59. :barattr:`Package-Type` is ``debug-token`` (debug tokens cannot be
  60. patched).
  62. 'Entry-Point` sections only appear if the effective package type
  63. is ``application``. Currently the system only actually supports
  64. one entry point per application; the last one specified wins. In
  65. older versions of the |BAR| specification, application
  66. capabilities were undifferentiated between system and user actions
  67. and were all specified at the start of the value of the
  68. :barattr:`Entry-Point` attribute in the form
  69. :samp:``[cap1,cap2,cap3]`; this form continues to be supported for
  70. backward compatibility, with the sole exception of the deprecated
  71. capabilities ``autoorient``, ``portrait``, and ``landscape``.
  72. Newer versions of manifest have
  73. :barattr:`Entry-Point-User-Actions` and
  74. :barattr:`Entry-Point-System-Actions` instead. (The old form is
  75. ignored if the new form is present.)
  77. The 'Archive-Asset' sections describe each ''asset'' in the BAR.
  78. An ''asset'' is defined to be any file (not directory) in the BAR
  79. which is not :file:`META-INF/{*.MF,SF,EC}` (i.e. signing related).
  80. A check for this is implemented as :meth:`is_exempt`. THe
  81. |BARSIGN| specification requires that each asset must have one or
  82. more digests listed for it.
  84. .. inheritance-diagram:: BarSection
  85. c���������C���sD���|�r'�|�d�k�r'�|�j��d�d���}�n��t�t�|����j�|�|���d�S(���s�
  86. Set the attribute `name` to `value` using the current locale.
  88. :param name: The mapping key to be set.
  89. :param value: The value to which the key is to be set.
  91. The :meth:``
  92. behaviour is specialized for BAR Manifest Files in only one
  93. respect: the asset names are normalized to use the POSIX path
  94. separator.
  96. .. rubric:: Implementation Notes
  98. It has historically been the case that BAR files generated
  99. and/or signed on Windows hosts have sometimes used the Windows
  100. path separator. (Although that may have been a tooling bug.)
  101. The |BARSIGN| specification does not make it clear which, if
  102. any, is correct. Accordingly, we do not reject the use of
  103. Windows path separators as an error.
  105. However, since the asset names are typically used as ZIP
  106. archive member names or as POSIX relative path names in the
  107. code, it is far more convenient to normalize them once here at
  108. the source than to force all potential clients to deal with
  109. the possiblity.
  111. Obviously, this also precludes legitimate use of the backslash
  112. as an asset name character (a usage forbidden neither by
  113. |BARSIGN| nor POSIX). However, this is probably best viewed
  114. as a feature.
  116. >>> s = BarSection()
  117. >>> s['Archive-Asset-Name'] = r'foo\bar'
  118. >>> s['Archive-Asset-Name']
  119. 'foo/bar'
  120. s���Archive-Asset-Names���\t���/N(���t���replacet���superR���t ���__setitem__(���t���selft���namet���value(����(����s8���/usr/lib/python2.7/site-packages/deckard/bar/manifest.pyR���q���s����%c���������C���s���d�|��k�r�d�St��j�|����S(���s��
  121. Guess the kind from the sequence of `keys` provided.
  123. :param keys: A sequence of key names.
  124. :type keys: sequence of |str|
  125. :returns: The 'kind' inferred from the `keys`.
  126. :rtype: |str| or |None|
  128. The empty string may be returned if there is no common prefix
  129. among the `keys`. |None| will be returned if no `keys` are
  130. provided.
  132. .. compound::
  134. The value returned depends on `keys`:
  136. 1. if they include :barattr:`Entry-Point`, then
  137. 'Entry-Point' is returned (because if that were the
  138. only key, the default guess would be just 'Entry');
  139. otherwise
  140. 2. the default guess from |Section.guesskind| is
  141. returned.
  143. >>> BarSection.guesskind(['Entry-Point'])
  144. 'Entry-Point'
  145. >>> BarSection.guesskind(['Entry-Point-Name'])
  146. 'Entry-Point'
  147. >>> BarSection.guesskind(['Application-Name'])
  148. 'Application'
  149. s ���Entry-Point(���R���t ���guesskind(���t���keys(����(����s8���/usr/lib/python2.7/site-packages/deckard/bar/manifest.pyR�������s���� c���������C���s?���|�d�d�d�d�d�h�k�r�d�Sd�|��k�r/�d�St�j�|��|���S(���s� ��
  150. Guess the name of the key attribute from the `kind` and the
  151. sequence of `keys` provided; the result will either be one of
  152. the `keys` or |None|.
  154. :param keys: A sequence of key names.
  155. :type keys: sequence of |str|
  156. :param kind: The kind of keys.
  157. :type kind: |str| or |None|
  158. :returns: The 'key' inferred from the `kind` and `keys`.
  159. :rtype: |str| or |None|
  161. .. compound::
  163. The value returned is governed by `kind` and `keys`:
  165. 1. if the `kind` is known not to have a key attribute,
  166. then |None| is returned; or
  167. 2. if the `keys` include
  168. :barattr:`Entry-Point-Localization`, then
  169. :barattr:`Entry-Point-Localization` is returned;
  170. otherwise
  171. 3. the default guess from |Section.guesskind| is
  172. returned.
  174. The first rule is primarily to arrange for 'Package' and
  175. 'Application' sections to be treated anonymously (despite
  176. having :barattr:`Package-Name` and :barattr:`Application-Name`
  177. attributes respectively). This is not really functionally
  178. important since they are singletons anyway, but it does ensure
  179. that this, like all other singleton sections, are stored
  180. anonymously for consistency. The other cases listed
  181. ('System', 'Debug-Token', and 'Patch') are only present as an
  182. optimzation since we were checking anyway; the default guess
  183. would have made the right choice anyway. For the purpose of
  184. this method itself, it is not necessary that the list be kept
  185. perfectly in sync with new |BAR| specifications (unless it is
  186. necessary for other reasons).
  188. The second rule handles the case of BBR localization files
  189. which use :barattr:`Entry-Point-Localization` as the key to
  190. match against :barattr:`Entry-Point-Name` in the manifest
  191. (while the BBR :barattr:`Entry-Point-Name` provides the locale
  192. specific value).
  196. A specialization of |Properties| for BAR Manifest and BlackBerry
  197. Resource Files.
  199. This class extends |Properties| with some methods which relate
  200. directly to BAR manifest handling. These are convenience methods
  201. for accessing various attributes, chiefly ones related to the
  202. 'Archive-Assets' sections.
  204. .. rubric:: Localization
  206. A BAR for which the manifest specifies :barattr:`Package-Locales`
  207. is expected to contain a BBR file for each named locale. These
  208. BBR files contain localized versions of particular attributes
  209. (:barattr:`Application-Name` and so on).
  211. In particular, 'Entry-Point` sections can be localized. Because
  212. they are named sections, it is necessary to match the each BBR
  213. 'Entry-Point' section with its correct manifest counterpart. The
  214. key in the manifest is :barattr:`Entry-Point-Name` (which also
  215. provides the default, unlocalized value); the key in the BBR is
  216. :barattr:`Entry-Point-Localization`, while
  217. :barattr:`Entry-Point-Name` provides the localized value.
  219. This is handled by :meth:`BarSection.guesskey`, which arranges to
  220. return :barattr:`Entry-Point-Name` as the key for manifest
  221. sections, but :barattr:`Entry-Point-Localization` for BBR
  222. sections. Thus, when localized by entry point section name, each
  223. BBR 'Entry-Point' section is merged with its correct associated
  224. manifest 'Entry-Point' section.
  226. .. rubric:: Implementation Notes
  228. This is actually really only of theoretical interest at the moment
  229. since only a single 'Entry-Point' is actually supported. However,
  230. properly handling this case provides an oppportunity to catch
  231. mismatches; a full implementation is also hopefully futureproof as
  232. well, at least at this level.
  234. .. inheritance-diagram:: BarManifest
  235. s"
Add Comment
Please, Sign In to add comment