Date: Tue, 6 Feb 1996 17:20:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: nate@sri.MT.net (Nate Williams) Cc: terry@lambert.org, nate@sri.MT.net, rkw@dataplex.net, hackers@FreeBSD.ORG Subject: Re: On keeping a src tree Message-ID: <199602070020.RAA03904@phaeton.artisoft.com> In-Reply-To: <199602062332.QAA05267@rocky.sri.MT.net> from "Nate Williams" at Feb 6, 96 04:32:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's failed since day one for me. Of course I started at 2.0.5 and I
> > don't "make world" often because I am a kernel hacker, not a utility
> > hacker. 8-).
>
> Hmm, I started with FreeBSD 0.9, and it's always worked for me. But, I
> also am a utility hacker and realize when certain things must be updated
> in order to keep my tools working. :)
Ah. That must be my problem. As a kernel hacker, I live by the premise
that "software doesn't mutate". Clearly, I'm being bitten by mutant
software ("Fleshy-headed mutant, are you friendly?" "No way, Eh? Radiation
has made me the enemy of all mankind").
8-).
> > Specifically, a CVS update with a changed tree failed when the rev on
> > the checked-out, changed file was not the same as the updated rev of
> > the same file in the tree.
>
> How can this happen? When you modify a file, neither the CVS entry nor
> the ID changes, so they should be in sync. When an update occurs, CVS
> attempts to 'patch' the modified file with the changes that were made in
> the baseline tree. If that patch fails to apply cleanly, then cvs
> doesn't fail but informs you the user that you must manually fix the
> problems since it can't be done automatically. Is this the 'failure'
> you speak of?
No.
1) SUP a CVS tree on a 2.0.5 system using 2.0.5's CVS.
2) check out a source tree.
3) edit a file that you know will change the next time a SUP
is done.
4) Do the next SUP, replacing the old file.
5) Attempt a "cvs update" of the tree containing the modified file.
6) Watch CVS puke its guts out because the rev on the line in the
CVS/Entries file for the file you changed is less than the rev
in the CVS tree, and the file is modified.
7) Update CVS.
8) Disable the client and server code, since 2.0.5 systems don't
have "struct MD5Context".
9) Build a new cvs.
10) Attempt a "cvs update" of the tree containing the modified file,
this time using the new CVS.
11) Watch it work like it should have worked before.
12) Get in a long discussion about mutating software with Nate. 8-).
> > Gross, disgusting, and time consuming.
>
> Necessary to keep things in sync, since it can't be automated.
Why the heck not? We used exactly this procedure with the older version
of CVS at Novell without incident.
> > I went from a 2.0.5-Release CVS to -current and it fixed it; whatever.
> >
> > It wants me to install the new headers for the MD5 stuff that the client
> > and server use to validate. Specifically, it wants "struct MD5Context",
> > which I don't have one of, not having rebuilt the world.
>
> I thought you went to -current?
No. I am running a -current kernel, minimal updated utilities, and I
*did not* go to -current on my entire machine. So I don't have the
updated header files installed.
You see, this is an SMP machine, and most of the time I am running an
out of date kernel so that I can use both processors.
Not that the source tree should be building using installed header files
anyway; it should be using the header files from the source tree.
Installed header files are useful only to provide a third-party with a
developement environment.
> In any case, in the same manner that you must libkvm when the kernel
> changes to have working tools, you must also rebuild libraries such
> a libmd when the tools which need them are modified.
>
> Even kernel hackers should be able to do this. :)
With respect, this is why "make" has the ability to resolve dependencies;
it should be possible for me to not give a damn what has changed beyond
the changes I personally cause. When I type "make" it should rebuild
everything that needs to be rebuilt, and *only* everything that needs
to be rebuilt.
Then it should be possible for me to specify an install target other
than my important OS, union mount the shadow tree with the modified
utils over the unmodified tree (which might be a CDROM) onto /altroot
or some other mount point, and then boot the new kernel and chroot to
/altroot to test the new stuff out.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602070020.RAA03904>