[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[todd@fries.net: Re: Status]



ooops, forgot to 'group reply' ;-)

----- Forwarded message from "Todd T. Fries" <todd@fries.net> -----

Date: Mon, 11 Sep 2000 08:10:03 -0500
From: "Todd T. Fries" <todd@fries.net>
To: Hubert Feyrer <hubertf@netbsd.org>
Subject: Re: Status
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.GSO.4.21.0009100507090.29497-100000@rfhpc8320.fh-regensburg.de>; from hubertf@netbsd.org on Sun, Sep 10, 2000 at 05:15:39AM +0200

On Sun, Sep 10, 2000 at 05:15:39AM +0200, Hubert Feyrer wrote:
[..]
> 2. We need to sort out what to do with FreeBSD 'chroot' builds vs.
>    OpenBSD 'FAKE' builds. They both seem to do ~the same. For a general
>    bulk build framework, I'd like to keep NetBSD's scheme in the
>    background, which builds pkgs only when needed; it should probably work
>    with either 'fake' and 'chroot' build.

Suggestion re fake vs chroot.  I can imagine they both have  different targets,
I'd believe they would both work well together, and initially to compare, since
some of us are not 100% familiar with both (read most), making them both
work would be education for us all, no?  NetBSD's method of `minimal disk
footprint' is ok to add, I may use it on a few machines, but anything I
do any serious development on has space to build all ports without running
out of space.  The `minimal disk footprint' is good in the special case of
spending time to eek out disk space.  I will generally skip this to buy more
build time .. but this is what its all about, options, right?? ;-)
 
>    Are there any descriptions on how these two systems work? (I know
>    there is one for the 'FAKE' builds, but I lost the URL... Marc, can
>    you remind me, plesae?)

I think you meant mirroring-ports, which is available via the FreeBSD or
OpenBSD man page web forms.  `fake' has been described here, before.  I'll
recap:

	Fake creates work/fake-${FLAVOR}-${ARCH}/usr/local from the mtree
	template and then sets DEST and PREFIX accordingly .. when doing
	the install phase of a package that does not have 'FAKE=No' ..
	The package is then built from this 'work/fake-*' directory tree,
	and if desired it can be installed on the real system, but this is
	optional.

	For example, I have a fast machine with lots of disk, and a slow
	laptop.  I don't need kde on my fast machine, it doesnt run X.
	I did 'cd /usr/ports/x11/kde/base; make package' and when it was
	done I didn't have kdebase installed, it was a package, and I made
	my /usr/ports/packages/ a link to the directory
	ftp://eclipse.fries.net/pub/fh/packages-i386/ and simply did a
	pkg_add ftp://eclipse.fries.net/pub/fh/packages-i386/All/kdebase-1.1.2.tgz
	and bing, installed on my laptop w/out being installed on my build
	machine.

	Granted, kdelibs-1.1.2.tgz is installed, because currently fake does
	not use -L/usr/ports/x11/kde/libs/work/fake-i386/usr/local/lib when
	building kdebase, but this is a trivial thing to do in the future.  You
	get the idea of the potential today.

>     * We import pkg_* tools and a set of pkgs from NetBSD. The reason is
>       that there's wildcard support in there that to add to something else
>       would be a PITA.
We'll have to make sure and get any bugfixes ported over.  I know there were
some issues regarding screen having a file named /usr/local/bin/screen being
a link to /screen-2.9.5, which is clearly wrong.  Maybe there are others ..

>     * Maybe add some more tools to be consistent (lukemftp, ...)
I fail to recall mention of this.  What is 'lukemftp' and what does it
do that fetch in freebsd and ftp in openbsd doesn't already do with appropriate
'*.mk' tweakage?

>     * We'll need some autoconf'd environment to get all these going on
>       all our target platforms[1]
I think the sys.mk from each respective bsd should set enough unique variables
and os version info that we shouldn't have to do much more than testing
variables.  Or am I missing something?

>     * Add FreeBSD 'chroot' builds or OpenBSD 'fake' builds, see above
I recommend `and' ..

>     * Using pkgtools/port2pkg, we can start migrating all FreeBSD ports.  
>       This will take some time, but it's mostly mechanical work (throwing
>       out MAN, ...)
Some mechanical, but some painstaking verification needs to be done as well.
And how does a port get ranked as 'working'?  For example, kde compiles and
installs (1.1.2) on OpenBSD, yet kdm cores.  I hear 2.0 will be better ...

Instead of replying to the 2nd email I saw, I'll just mention it here.

Regarding the concept of build environments and multiple archs, has anyone
ever seen plan9 build programs?  It builds all arch's at once, so that
on any given node, the same binaries are always available.  I know it
would be some effort, but I believe it is doable to allow cross tools
to be properly configured so that one system could concievably build
binaries for any OS/arch combination.  Of course that would be a lenghty
undertaking, but .. well worth the effort imho.

-- 
Todd Fries .. todd@fries.net

----- End forwarded message -----

-- 
Todd Fries .. todd@fries.net

To unsubscribe: send mail to <majordomo@unixathome.org>
with "unsubscribe bsdports" in the body of the message