Re: Unidentified subject!

[Tom Lees <tom@lpsg.demon.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

On Fri, 21 Feb 1997, Mike Neuffer wrote:

> I would just wish that some people would really as I suggested before take

Alright... but it looks like you outline this below, so here goes...

> a close look at what FreeBSD is doing. Defining an essential core system
> (ca. 60-100MB installed binary size) that contains everything an Unix
> system needs to run _properly_ is an essential step. 

We are supposed to use Priority to do this. We can modify dinstall (or
whatever) a bit to handle this creation of a source tree for all packages
priority (standard or above).

> The sources for this system should be in ONE source tree so that it can be
> build with one command (known as "make world" in all BSD and most
> professional Unix systems). This will give us one essential system
> where everything fits together and where you have no problems because one
> developer compiled a package in this or that special evironment. It would
> also make sure that all packages are really compileable.  

OK, so we need to include the compilers and development tools needed to
compile the base system in this (gcc, binutils, bin86, make, etc). Or
maybe do it a different way. If the essential development tools are
installed separately, we could have a "make devel-sync" (which world
depends on), which will check re-synchronize the development tools. This
would involve re-building binutils, gcc, and libc, then re-building them
again with these versions (extension of the 3-stage compile of gcc):-

	* Build make using current tools
	* Build binutils using current tools
	* Build gcc using new binutils (upto stage2)
	* Build libc using new gcc
	* Build binutils using new gcc/libc
	* Build gcc using new binutils/libc (stage3)
	* Build dpkg and co using these tools
	* Build debian packages of all these tools from the binaries we
	  are using to do everything else
	* Build make using new tools

All other development tools are not interdependent, so there is no
problem, these can be done as simple dependencies, and this lot is so
small, it might as well be black magic.

> The whole system could essentially be tarred together and dumped on a new
> machine. This is how it works in *BSD. You have ONE bootfloppy, that is
> able to get the chunks (the tarfile is beeing chopped in handy chunks that
> fit on a floppy) via ftp from one of the ftp<n>.<country>.freebsd.org
> machines or from floppy or from CDROM and that essentally untars the
> system on the harddisk after partitioning it.

What we do is to tar enough of a system to get dpkg up and running to
install the rest of the packages. This bit is fine IMHO.

> You have basically only 4 choices for basic configurations:
> 
> Development machine with or without X11
> and user machine with or without X11
> 
> Once this is done you can in FreeBSD use pkg_add, pkd_delete, etc
> to manipulate additional packages. (This could be improved with
> a dselect2 or whatever it might be called)

OK, we should do something similar.

> If you want to update your system you just cd into /usr/src
> and do a make world and your whole system is beeing recompiled and 
> updated (no need to shut down the machine).

This is also possible - you make world, we re-synchronizes the development
tools first, then rebuilds everything else.

> To update your sources you simply use cvsup which gets controlled 
> via a tiny config file the newes diffs to your current source tree
> and applies them. A make world again brings your system uptodate
> and all programs, libs and compilers are in sync since everything gets
> build properly.

This is where a CVS'd source tree would be useful. We can use an
automatically recursing Makefile (like my example) to do this.

> The same is true for add-on packages, which reside in /usr/src/ports.
> Or to be more exact the makefiles and diffs reside there together with the
> information in the Makefile how and where to get the latest version.

Hmmm... local packages are not really our concern here, and I don't think
that this concept fits in well even in FreeBSD.

> Building something like this would defintely not be easy, but it would
> make sure that we have a core system where everything REALLY fits
> together.

It wouldn't be as difficult as it seems if we did it our own way not BSDs.

- -- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBMx83Hv152HGH1NBlAQFicQP/VmvPvs/w/Mil6SeIqnmmrmB2I4zzWz0X
x0/ZgbVEWG/T85oI/JmAeby3V/yoOZVi3KYwxO7F0MFUOjE9IvVpybZ2dKKiakdJ
FI8n2/OhMiPlTdU4kyrFT21Fz74rvfpsXcsE5STsqrAamFKzDM2qmfrNLtuXgvzD
RBDWF4a/hnE=
=Aa3r
-----END PGP SIGNATURE-----

# Makefile to recursively call itself looking for debian package directories.
# GNU make dependent

SUBDIRS=$(shell find -maxdepth 1 -type d \! -regex \\. \! -regex .\*\\.orig \
	| sed 's:^\./::g')

ifndef TOP_MAKEFILE
TOP_MAKEFILE:=$(shell pwd)/Makefile
DIR:=[top]
endif

ifneq ($(wildcard debian/control),debian/control)
all: do-subdirs
else
ifeq ($(wildcard devstamp),devstamp)
all:
	@echo Ignoring: $(DIR) - is a development tool
else
all: buildstamp
endif
endif

buildstamp: srcstamp
	@echo dpkg-buildpackage -b in $(DIR)
	@echo touch buildstamp

srcstamp:
	@echo [no source stamp in $(DIR)]

do-subdirs:
	@for i in $(SUBDIRS); do \
		make -C $$i -f $(TOP_MAKEFILE) all DIR=$(DIR)/$$i TOP_MAKEFILE=$(TOP_MAKEFILE); \
	done