Xref: utzoo unix-pc.general:3951 comp.sys.att:7887
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!andante!ulysses!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: unix-pc.general,comp.sys.att
Subject: Re: One 3B1: questions on going from 3.5 to 3.51?
Message-ID: <1684@mtunb.ATT.COM>
Date: 26 Oct 89 02:16:14 GMT
References: <1763@naucse.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Organization: AT&T ISL Middletown NJ USA
Lines: 59

In article <1763@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes:
:
>	(1) The installation guide claims that the 3.5 development
>	    set will not work with the 3.51 foundation set.  True?

		There _IS_ a serious problem, but NO ONE can recall
		what it is!  (I never heard of it until now.)  Some
		folks remember that they'd heard reports of trouble,
		while others say they they ran with that combination
		with no problems.  (Great help... sorry.)

		Since 3.5 object codes work on a 3.51 system, the
		incompatibility would seem to lie in:
		a) replacing a 3.51 file with an older version
			while re-loading the 3.5 Dev.System --
			thus crashing 3.51 codes -- OR
		b) building an object code using some file from
			3.51 that is incompatible with the 3.5
			pre-cursor -- thus creating un-runnable
			new object codes.

		The only file _I_ know that is common to both the
		OS set and the development set is "/bin/ld".

		Consider waiting for a clarification from someone:
		I'll ask around here tomorrow.
:
>	(2) I've got a fair amount of odds and ends out there
>	    (pty and other lddrvs, patched iv, etc.) that seem
>	    like they will be affected in going from 3.5 to 3.51.
:
		We're still loading drivers developed on 3.0.
		Expect fewer problems than you currently encounter.
		(Yes, it is POSSIBLE you have written something
		peculiar enough to require 3.5 -- but very unlikely.)

>	(3) I'm getting sick just thinking about all the floppies
>	    that I'm going to need to back up the disk(s).  Will
>	    the following approach work:
:
		The only problem I'd intuit is a need to alter your
		new (3.51) /etc files to mount your additional
		File Systems.  (You may have the MOUNT information
		in a form that will survive the upgrade w/o ANY
		changes.)

>        (4) Since the stuff I want to save is spread all over
>	    the place (for example, the improved 'rc' from ICUS
>	    is in /etc) is there an easy way to restore those
>	    things selectively (see question 2 above)?

		There are so many ways you can make up a long list.
		The challenge has always been to KEEP TRACK
		of the files you want to replace, not to replace them.
		You shouldn't have any problem accessing your 2nd disk
		File Systems (after you've mounted them) following the
		upgrade, so just make sure the files you want ARE THERE.

jc mcmillan	-- att!mtunb!jcm	-- speaking for self... not THEM