Review for Package: libunicode-string-perl

[Summary]
MIR team NACK
(indirectly, since libunicode-escape-perl got a NACK)
Once resolved there this can be re-considere. In that case it would be a usual
ack under constraint to resolve the required todos below.

This does not need a security review

List of specific binary packages to be promoted to main: libunicode-string-perl
Specific binary packages built, but NOT to be promoted to main: n/a

Notes:
Required TODOs:
- give it a reasonable evaluation please if the need for this from the
  depending package might nowadays be fulfillable with perls native unicode
  support that it has.
Recommended TODOs:
- The package should get a team bug subscriber before being promoted

[Duplication]
There is no other package in main providing the same functionality.

But that is only true if one insists on the old style handling.
Newer perl supports unicode and the package states that itself:
"These modules predate native Unicode support inside Perl.  Normally, the
integrated Perl Unicode support and modules such as Encode should be used
instead of these modules."

We should avoid picking this up by accident, unless the dependency triggering
this does strictly need one of the few special features here it should be
better to get rid of the dependency to this old module.

Please start those checks at libunicode-escape-perl which has a similar
problem and if that isn't needed then libunicode-string-perl is not needed
either.


[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]
OK:
- no embedded source present
- no static linking
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used, all Built-Using are in main

Problems: None

[Security]
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- 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)

Problems:
- does parse data formats (usually docs in the current use, but not arbitrary
  and low attack surface)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
- no special HW needed
- no new python2 dependency

Problems: None

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Debian/Ubuntu update history is slow (matching upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- It is not on the lto-disabled list

Problems:
- Upstream update history is slow, not sure how much we can rely on it.
  Those kind of packages often are without being a problem, but we have to
  be clear this seems like a non (much) active upstream.

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl only)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks
- no translation present, but none needed for this case

Problems: None