Bug#165358: workaround for __libc_fork and winex 2.0
At Sun, 3 Nov 2002 22:09:39 -0500,
Daniel Jacobowitz wrote:
>
> On Sun, Nov 03, 2002 at 09:13:33PM -0500, Jeff Bailey wrote:
> > On Sun, 2002-11-03 at 20:24, Daniel Jacobowitz wrote:
> > I think we should simply make sure that Sarge's release notes indicate
> > that certain commercial programs (Java, WineX) had been incorrectly
> > using the C library and may need to be upgraded to keep them running.
>
> __libc_waitpid's hiding is not interface-related, it's
> namespace-related. There are no changing interfaces involved, and it's
> clear that we can safely continue to export it unless there's a major
> change. __libc_fork similarly. If we make the symbol unavailable at
> link time - there's plenty of examples of this in glibc - then bad
> binaries can no longer be built on Sarge; then a release later we can
> stop supporting them. I believe that the only fair thing for our users
> is to allow a transition period. This is the first release which
> enforced the namespace rules; it was not very clearly documented
> before.
I agree, too.
We should take a transition period for many users. Some user read
sarge release notes, but other user does not read such a long
expressive documents. Some user can upgrade easily, but other user
cannot move to new JDK or such buggy software because of its own
circumstances.
Yes, we have to warn "for developer, you don't use such an internal
symbol", but from user point of view "I don't know such a export
issue, because I am a user". Sarge release documents only say some
commercial programs do not run after sarge, so we recommend to
upgrade such softwares.
In addition, the most important benefit is "we don't see this kind
of BTS" :-)
Jeff, would you reconsider it?
Regards,
-- GOTO "MSX1/2+ is the starting point of my computer experience" Masanori
Reply to: