Date: Mon, 31 Mar 1997 17:23:48 -0600 (CST) From: "Lee Crites (AEI)" <leec@adam.adonai.net> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: FreeBSD-Ports <freebsd-ports@freebsd.org> Subject: Re: Error installing pine-3.96 Message-ID: <Pine.BSF.3.95.970331164932.792B-100000@adam.adonai.net> In-Reply-To: <12424.859846640@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Mar 1997, Jordan K. Hubbard wrote: =>> I have two decades of computer experience. I've done just about =>> everything once (and some things I don't want to admit to more than once =>> -- anyone need a cobol programmer anymore?) => =>Lots of people, actually - cobol programmers are going to make =>a fortune these next few months in turning all those "PIC(2) YEAR" =>statements into "PIC(4) YEAR" for the Y2000 problem. :-) Yup. I've thought of getting into the foray, but I'm not sure if I want to take on the liability, and the thought of wading through decades of spaghetti code makes me nauseous... =>It's too hard? :-) => =>For one thing, you can't give it its own partition since only the =>first 0xA5 type partition is booted from and I can't really imagine =>how you'd make multiple versions co-exist in a single partition. I must admit to having some ignorance in this area. And, additionally, our code was not an os, so we didn't have to worry about booting. However, can't a person enter the name of the kernel? I know I put all of my old kernels into /kernels, so when I wanted to reboot using an old version, I entered /kernels/kernel.original. By dumb luck, /kernels is in the book partition. Would this work if I had put /kernels into another partition? This is a question I am interested in since I was thinking of putting it elsewhere... =>If our upgrade supported proper versioning, it might be easy enough to =>go *backwards* if you didn't like an upgrade and wanted to undo it, =>but I can't see anything fancier than that working out. We didn't try to go both ways on our versions, either. In fact, we just went one way -- forward. We'd make the change to an early version (say 2.1.5 for fbsd purposes), then move it to 2.1.7, 2.2, 2.2.1, then, finally, to 3.0. However, my thought would still make that easier, I think. If you could boot to kernel.2.1.5, which would use /bin.2.1.5, etc. If you had one system set up like that, you could use it to test/develop on as many platforms as you had disk space to hold. Now... I have no clue if this is possible. It's just how we set up our code base vs our executables base. What I was thinking of doing was put one box on my lan, and using cvsup or ctm, get it up to date with the latest and greatest code. I'd then put another box on my lan for my most stable version (2.2.1?), It would stay up-to-date with periodic background compiles and such -- using the main code base box as the source. I'd keep another box with the 'production' version -- the version of the os that all of the other boxes were on. Any time I had a problem, I'd check it on both boxes. Once the 'stable' box passed all testing, I could copy, via nfs, the executables to the other boxes and reboot them. This way, if something happened (...perish the thought...) which caused the latest version of the os to be unstable/unusable, I'd know it before my customers did. This is the only way I can see to keep everyone stable and up while still trying to keep somewhat up-to-date with the os. Since the code base box will only act as a server for the code being compiled on the other two boxes (via nfs, most likely), it shouldn't have any problem, and sine the only thing the other two will do is iterations of make world, if they crash nobody will care. Can you see an easier way to do it? How do the rest of you keep up and remain stable? Or do people who need a stable system just stay on the same version until forced to upgrade? Lee
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970331164932.792B-100000>