[MIR] unicode-cldr-core

[Corey Bryant]

[Availability]
Currently in universe.

[Rationale]
This package provides common data from Unicode CLDR (core) that is used by python-babel.

[Security]
No security history.

[Quality Assurance]
Package works out of the box with no prompting. There are no major bugs in Ubuntu and there are no major bugs in Debian.

[Dependencies]
No dependencies

[Standards Compliance]
FHS and Debian Policy compliant.

[Maintenance]
Simple package that the OpenStack Team will take care of.

[Background]
The common files that are now provided by unicode-cldr-core were previously vendored into python-babel. In Kinetic you'll see a common directory in python-babel's package source. In lunar that directory no longer exists, and instead debian/rules runs python3 scripts/import_cldr.py /usr/share/unicode/cldr/common.

[Christian Ehrhardt  (paelzer)]

Review for Package: unicode-cldr-core

[Summary]
MIR team ACK under the constraint to - as much as possible - having a
look at the recommended TODOs below.

This does not need a security review

List of specific binary packages to be promoted to main: unicode-cldr-core
Specific binary packages built, but NOT to be promoted to main: <none>

Required TODOs:
- none
Recommended TODOs:
As always, there are more details below about these
- #1 There is translation test data, consider adding an autopkgtest
     that ensures this isn't ever broken.
- #2 please commit to help Debian to update more often
- #3 implement package split [1] for footprint and adoption

[Duplication]
There is golang-github-go-playground-universal-translator based on the same
dataset, but that is less maintained, less re-usable and relatively out of
date. There are more like python3-unicodedata2 libghc-unicode-data-dev
which all provide unicode data - but not as a reusable data set as provided
here (and not in main).
In theory ICU contains the same data and is in main, but isn't usable for
the purpose it is needed here.
=> There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
- no embedded source (actually no source at all) present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard

Problems: None

[Security]
OK:
- history of CVEs does not look concerning (this is only data, no code)
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not open a port/socket
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certificates, signing, ...)

Problems: None

[Common blockers]
OK:
- does not FTBFS currently
- This does not need special HW for build or test
- no new python2 dependency

Problems:
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
=> That would usually be a problem, but here this is really just a data set
   to be used by other programs and has no active code.
   There is test data provided in the source as "Data for testing expected
   behavior of CLDR operations" it seems not required, but still nice
   if an autopkgtest could utilize those. Just to ensure nothing unexpected
   ever breaks this. I'm happy if this it at lesat tried or shown that it is
   already done at another level like...