Q. about the way libc6 is packaged (looking for inspiration)
I started packaging ICU 1.6 the way libc6 is packaged, or similarly to:
libicu16: contains all the lib*.so.*, plus some /usr/sbin/xxxx tools, plus
some converter data in /usr/share/icu/18.104.22.168/
But then I realized that when ICU 1.7 is released, I'll have:
libicu17: contains all the lib*.so.*, plus some /usr/sbin/xxxx tools, plus
some converter data in /usr/share/icu/1.7/
(in ICU, any of the major and minor version number may change to indicate a
binary incompatible release, so they're combined in a big major here).
If I install this package on top of libicu16, I'll get a lot of warnings
about overriding the non-lib files. Then if I remove libicu16, I'll lose
these files, right? (They'll be deleted blindly.)
So I'm thinking about splitting into:
libicu16: just the lib*.so.*
icu: the rest, depends on libicu16.
Is that a good idea? How does libc6 sidestep the issue? Or will any libc7 be
declared as conflicting badly with libc6, and then maybe a libc6-compat
My opinions do not necessarily reflect my company's.
The opposite is also true.