© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
As far as I've read the code so far, it looks like overly-complicated pre-C++-11 code: I don't think I've ever seen so many 'new' and 'delete' calls in a source package before. As one concrete example -- there's a StringBuffer class. I can't figure out *why* there's a StringBuffer class, as C++ already has std::string. (It *might* be to make it easier to work with C-strings alongside std::string -- I can't speak to how well or poorly that actually works in C++ -- but I do know that I've never seen a StringBuffer implemented in C++ before.)
So, a few questions:
- Mecab was in our MySQL packages previously. Was it vendored in by Oracle or by Debian?
- I understand Debian is dropping MySQL. Is this merge from Debian our last?
- When Mecab was vendored in to mysql source packages, we could at least examine discovered flaws with knowledge, however poor, of how Mecab was going to be used by exactly one package. With Mecab in main on its own, we may not have that luxury, and may need to support this tool for far more issues than before.
So: if there's no future in syncing MySQL package updates from Debian, is this part of the change actually useful? Does having this separate package benefit anybody? What do we lose by returning to our previous MySQL packages and keeping the tarball updated as Oracle releases them? (Does Oracle actually provide security support for Mecab in this hypothetical configuration?)
Thanks