Re: linux-ipsec: Comments on the INSTALL process of the 1998jun14 snapshot

Some random comments on Hugh's comments...

> 4: Humm, doing the make install before successfully compiling the

This is a difficult problem; one really wants to do a synchronized update of both, but one has to come first. Doing the kernel first would make some sense, but it does mean adding the awkward "cd back to wherever you put the sources" step that drew criticism from Certain People in earlier versions.

> 10: What doc might I want to browse? Where? What files?

Basically, the docs that aren't written yet. :-(

> .9 second disaster, witness:
> I am pretty sure that the problem here is that I was using a virgin

Fixed in the docs, although possibly I could go further and have the top-level Makefile check for and diagnose the situation. (I've found it's almost always better to do this than to write, for the 50th time, "the symptoms you describe clearly indicate that you did not read Step 1".)

> Another opps:
> root@east > make clean
> make: *** No rule to make target `clean'. Stop.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Fixed, I think.

> Another opps: I ^C'ed the make when it was in something (GMP I

This gets into arcane makeology, although I think a lot of it can be fixed easily when I get to clean the backward-compatibility junk out of the top-level Makefile. (The underlying problem is that "pluto" is both an arbitrary make-target name and a directory name right now.)

> Looking at the make file I see that it: is the first target when I

I can change the internal name easily enough, although I worry about people thinking that "all" includes the kernel. I am tempted to go back to requiring an explicit make target for the user-level compile, for just that reason.

> ...Doing a "make clean" at the top level should decend

Fixed.

> Maybe you should tell folks to check for errors in the output of the

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

Sure would be nice if the makefiles were properly written... Any thoughts on the best strings to sweep for to check for errors in a Linux kernel compile?

> Dam, I got caught by the "#INSTALL_PATH=/boot" bug AGAIN! Look,

Fixed in the docs. Again, an automatic check might be a good idea.

> hugh@east $ barf

Sigh, CVS notices the permissions on the file when you first check it in, but doesn't seem to notice changes made thereafter. Fixed, I think.

> Humm, there is no RCSID at the top of the INSTALL file, or barf.

I need to make a systematic sweep for such things at some point. However, I do tend to think such things should go at the bottom rather than the top, to avoid the "wade through three screens of automatically-generated junk before you get to any useful text" syndrome. Comments?

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)