From owner-freebsd-current Mon Feb 12 14:11:31 2001 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 6456E37B491 for ; Mon, 12 Feb 2001 14:11:28 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id RAA14085; Mon, 12 Feb 2001 17:10:59 -0500 (EST) Date: Mon, 12 Feb 2001 17:10:58 -0500 (EST) From: Daniel Eischen To: Warner Losh Cc: John Indra , freebsd-current@FreeBSD.ORG Subject: Re: -CURRENT is bad for me... In-Reply-To: <200102122150.f1CLoWW31812@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Feb 2001, Warner Losh wrote: > In message Daniel Eischen writes: > : On Mon, 12 Feb 2001, Warner Losh wrote: > : > To be blunt, the FILE * changes go too far, even for -current. > : > : Other than having to installworld twice, I've had zero problems. > : But I don't recompile my applications often, and am probably > : still running things that depend on libc.so.4. > > I have lots of binaries that depend on libc.so.5 (I just checked) and > none that depend on libc.so.4 or libc.so.3 (since those were removed > from my system a while ago). I suspect many of them will break. > > : > Changes of this magnitude require a bump of the major number, even > : > though we've already done that in -current. It breaks nearly > : > everything, including the upgrade path. Alternatively, the locking > : > changes need to be backed out. > : > : Too bad ELF libraries don't have minor version numbers. It's > : a shame to waste a library version number. > > Don't think of it as a waste. > > : > Alternatively, the upgrade path must be fixed. We've managed to avoid > : > extra special instructions in the vast majority of cases, and I don't > : > want to start introducing them now. It is the road to madness. We > : > tried that once before and the support load was too high. > : > : I don't have the time or resources to fix the upgrade path. If > : someone else wants to, it would certainly be appreciated. > > Then wouldn't the "partially applied patch" rule apply? eg, back it > out until the issues can be resolved. Breaking the upgrade path isn't > acceptible. If you bump the library versions, doesn't that fix the upgrade path? I can think of a gross hack that gets around the problem for now. Allocate the FILE with enough storage for the lock, but don't declare it in FILE. __sF[3] would still be the same size and we could have __sF_locks[3] internally, and use these if fp is stdin, stdout, or stderr, else the lock is at the end of the struct. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message