Date: Wed, 23 Oct 2002 16:02:40 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Juli Mallett <jmallett@FreeBSD.org> Cc: Brooks Davis <brooks@one-eyed-alien.net>, Steven Ames <steve@virtual-voodoo.com>, Andrew Mishchenko <andrew@driftin.net>, freebsd-current@FreeBSD.ORG Subject: Re: Request: remove ssh1 fallback Message-ID: <3DB72A90.771AACE2@mindspring.com> References: <20021023155753.GB7503@HAL9000.homeunix.com> <004401c27aad$740a5400$33d90c42@officescape.net> <20021023161643.GA7813@HAL9000.homeunix.com> <20021023143917.GA3222@driftin.net> <3DB6F2E1.799FF6F7@mindspring.com> <009001c27ac8$af6d77f0$33d90c42@officescape.net> <20021023123349.A9132@Odin.AC.HMC.Edu> <3DB6FF07.5DAC9CCB@mindspring.com> <20021023131051.A21930@Odin.AC.HMC.Edu> <3DB722CA.2A6E6482@mindspring.com> <20021023154350.A97759@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Juli Mallett wrote: > * De: Terry Lambert <tlambert2@mindspring.com> [ Data: 2002-10-23 ] > [ Subjecte: Re: Request: remove ssh1 fallback ] > > [snipped] > > You're essentially arguing that upgrade should not change anything, but > somehow that moving old stuff out of the way should be done? No. I'm arguing that configuration dictates behaviour, and perceived behaviour should not change. > How is it exactly that you propose we take care of the include namespace > breakage that GCC has introduced in an automated way, without possibly > doing the wrong thing? The easiest approach would be the one SCO used, starting in 1986, where installed files are registered into a global database by component and version, and when an upgrade occurs, and the component is changed, those files which are from the previous component and not replaced by the new component are removed from the system. This is not something that can be dealt with this way at this late a date, unfortunately. It was probably a mistake to change the compiler version, without either dealing with this, or by versioning the include directories used, so that the new compiler could not see the older header files. Versioning the include directory is still an option, and would fix the problem (e.g. /usr/include/g++3_2_1). The fix would be both effective and immediate. > If we're going to account for people modding their system > then we have to leave it up to them, and the people who don't mod even, > really, their rc.conf, to nuke the includes stuff. That's one option: make everyone do the labor, rather than having one person deal with it in source code. But it's not the most overall labor-efficient option. > Besides, upgrading a production system in-place is almost never worth > the effort it entails, on any system. Version skew, security issues, > etc., all make this a less-than-enjoyable option. Then remove the "upgrade" option off the sysinstall menu, and be done with the issue: "Upgrade not supported for 5.0". This isn't a realisitic option; even though you claim it is almost never worth the effort, I think most people want it anyway, despite what you think about the practice. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB72A90.771AACE2>