Re: libc soname conventions [was: libc6_2.0.106-0.1_i386.deb is released]
Hi!
>>>>> Marcus Brinkmann writes:
MB> Why can't we just bump the soname each time the hurd-i386 glibc
MB> packages have an incompatible API change? Note that you can have
MB> multiple libc6 packages with different sonames installed, so old
MB> binaries will continue to work. The versioned dependency should
MB> be enough to handle all cases.
My proposal was only for the case of shared libraries that are linked
against earlier glibc's.
MB> We would then have libc0.2, libc0.3, libc0.4 etc packages, and
MB> binary packages depending on them. We would only maintain one set
MB> of development packages. Can you explain the drawbacks of this
MB> simple solution?
Say I have installed libncurses4_4.2-3, which depends on libc0.2.
What I get from your message is that if we switch to libc0.3, we'll
just leave libc0.2 installed until we compile libncurses4_4.2-4, so
that it depends on libc0.3.
If you make the assumption that everybody using Debian GNU/Hurd will
be doing a lot of upgrades anyway, then I don't see any real problem
with that approach.
Would you mind explaining in your own words why Debian uses the `g'
suffix for some packages? Your message implies that I have somehow
misunderstood the rationale. It seems to me that the same reasoning
you applied here to analysing my plan would also apply to Debian's
libc5->libc6 upgrade, in which case several packages were renamed when
they didn't need to be.
I'm not looking to blame anybody for gratuitous package
renaming... I'm just seeking to understand what actually happened
during the libc5->libc6 upgrade.
Thanks,
--
Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
[Unfortunately, www.fig.org is broken. Please stay tuned for details.]
Reply to: