Q. about the way libc6 is packaged (looking for inspiration)

[Yves Arrouye <yves@realnames.com>]

Hi,

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/1.6.0.1/

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
introduced?

Thanks,
YA
--
My opinions do not necessarily reflect my company's.
The opposite is also true.