Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Dec 1999 11:39:11 -0500
From:      Greg Lehey <grog@mojave.sitaranetworks.com>
To:        Andrzej Bialecki <abial@webgiro.com>
Cc:        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/release/picobsd Makefile src/release/picobsd/build Makefile Makefile.mfs
Message-ID:  <19991211113911.C355@mojave.sitaranetworks.com>
In-Reply-To: <Pine.BSF.4.20.9912111429220.86107-100000@mx.webgiro.com>; from abial@webgiro.com on Sat, Dec 11, 1999 at 02:46:13PM %2B0100
References:  <199912102143.NAA50148@freefall.freebsd.org> <Pine.BSF.4.20.9912111429220.86107-100000@mx.webgiro.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 11 December 1999 at 14:46:13 +0100, Andrzej Bialecki wrote:
> On Fri, 10 Dec 1999, Greg Lehey wrote:
>
>> grog        1999/12/10 13:43:10 PST
>>
>>   Added files:
>>     release/picobsd      Makefile
>>     release/picobsd/build Makefile Makefile.mfs
>
> I appreciate your work, and I consider it to be a step in right direction,
> but you should've discussed this with either me or Doug White before
> committing ( *cough* the word MAINTAINER comes to my mind). 

Indeed.  I looked for a Makefile, but I couldn't find one, so I sent a
message to FreeBSD-small asking what people thought.  I thought of
sending you a message separately, but you're on FreeBSD-small, and you
hadn't shown any activity for over a year.  You also didn't comment on
my suggestions there.  I didn't know Doug White had anything to do
with PicoBSD, but if he does, I would have expected him to be on
-small.

> The end result for now is that we have two conflicting methods of
> building the floppies, and neither works (you broke the "custom"
> target when building with 'build' script, 

There was no custom target.  All the commits are additional files
which don't touch the old build method in anyway.  I went to some
trouble *not* to break the old build method more than it was already
broken.  I don't believe it has worked for at least 6 months, maybe a
year.  I haven't been able to build any version, and the newest
PicoBSD images I found date to September 1998.  One example for "don't
break the old version" was that I would have liked to remove files
from the picobsd/floppy.tree hierarchy, but I didn't; instead, I
copied them to the image and then deleted them again in the Makefile.

But yes, we now have two conflicting build targets, and that's
something else to address in the mid-term.

> and your "custom" floppy doesn't compile because some Makefiles have
> 0 length).

There were some problems with the commit, which are being addressed.
That's not a permanent situation.

>>   Log:
>>   Add 'custom' directory with significantly restructured build (now
>>   using make instead of custom scripts) and two floppies instead of
>>   one.  The resultant floppy can do everything that the individual
>>   floppies (dial, net, install, isp, router) could do, modulo some bit
>
> Well, not really. The individual floppies were there for a reason: smaller
> memory footprint. While it's becoming of less concern nowadays, there is
> still a lot of people with old junky 486 with 8MB SIMM RAM. A general
> purpose, one-size-fits-all floppy doesn't work for them.

As I said, they won't build under -CURRENT.  The kernel has got too
big.  But I haven't changed anything in this area.

>>   floppy will run fine by itself, but the size of a compressed kernel
>>   has increased by nearly 50% since 3.2, and there's not much space for
>>   anything useful on the remainder of the floppy.  The current method
>
> It depends on what you want to put on mfs. If you consider e.g. the
> original "router" floppy, you could do even with 4MB RAM, which is
> important for embedded systems.

I would like to do this.  Maybe a kernel without any hard disk support
can do this.

>>   creates a larger mfs and can read as many floppies as the user can
>
> It's a good feature, as I said. We just need to discuss the whole picture.
> (BTW, I don't want you to back it out. I want you to fix it :-)

Sure, I want to fix it too, if it's fixable.  But remember, nothing
has changed with the "old-style" build.  I'll address that at a later
date.  What I see happening is: 

First, move to a Makefile-based build.  This will enable automatic
builds, so people making changes will see when they break something.
At the moment, I can't compile ppp and something else (passwd?) which
I've forgotten.

Next, fix the old builds.  I chickened out in the custom build and
just commented out the programs that didn't work.  We need to go back
and fix those builds.  Also, there are some programs, like tcpdump,
which I would like to include, but which don't build because of their
unusual source dependencies; if you know how to teach crunchgen to
build tcpdump, I'm sure many people would be happy.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991211113911.C355>