[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The future (dependencies on libc{5,6,6.1} &c)


The decision on how to name our library packages the way we do was
made to deal with specific technical issues, not aesthetics.  The
decision was made after much debate---if you like, please review the
debian-devel lists from October/November 1995 for the full scoop.

I think that contravening this policy---however informal it may seem
to those who weren't there when it was hashed out---would be a grave
technical error, and I will not condone in it unless I am shown a
specific instance where deviating from that policy would solve a

(In fact, RedHat is stuck at the alpha-level glibc specifically
because they didn't create a similar policy---and when major interface
changes were introduced at the end of the development cycle, after RH
had a formal release out, they couldn't upgrade because they didn't,
and still don't, as far as I know, have any way to do the upgrade
without things that are dependent upon the old interfaces breaking in
the middle of the process.

I'm still curious as to how they're going to manage.  I know people
who've been installing the unofficial glibc-release packages always
seem to have trouble.)

You write:

> It's probably more confusion to move away from [libc6 = glibc2] than
> to allow a package name not to reflect the soname.

I am baffled that you would propose that we spend many dozens (if not
hundreds) of hours recompiling all the packages on the system based on
a _possibility_ of confusion.

Now I realize that you might think there's a quick fix in simply
making a new libc6 package that "Provides: libc6.1", but consider
this: glibc2.1 will probably have a soname of 6.1 on everything but
the alpha, so when glibc2.1 comes out things will almost certainly
break, as they'll not know that the new glibc needs to be installed.

Or maybe glibc2.1 will still use the soname 6, at which point, guess
what, this whole discussion will have been rendered moot, as the
confusion will exist upstream.  Should Debian then keep the source
package as 2.0?  Or should it change the package name to 6.1?  If it
does, do you expect the soname to change as well?

Any way you slice it, I don't think there's *anything* to be gained,
and a lot to be lost, and confusion will only increase.

Please, let's find something more productive to discuss.


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: