Re: gar2vcheck

Paul--

Absolutely I'd be interested in including the chroot(s), initially. I 
view this as a bootstrapping process: initially we'd make the build 
self-contained by packaging the chroot'ed build environments, but 
ultimately the build would be able to produce a chroot image or a 
virtualized image so that the entire process could occur from source. 
Kind of like compiler bootstrapping.

As I said, if I recall the way things worked, we'd be fairly close to 
what I described as the ideal. Here are the things I remember being 
missing...maybe you can correct or update me:

-- While a garchive could be used to locally aggregate most sources, 
some of the sources, particularly the internally developed ones, didn't 
have adequate versioning info to prevent aliasing a new version over an 
older version, so that if you had updated and then tried to build from 
an earlier copy of gar, you'd get some mismatched source, and the build 
would fail. My main objective here is that a user could check out any 
version of gar from the repository beginning with the earliest date of 
their garchive and as recent as their most recent addition to the 
garchive, and generate exactly the same output system each time.

-- The system was not far from, but couldn't self host. Even though the 
sources included the development tools, the goals of the system were 
fixed at generating a bbc-sized image, and a bbc-like functionality. It 
seems to me that gar is much more general than that, and if it were 
parameterized properly could build a family of systems, all sharing a 
minimal core of packages, and all coming from a common package and 
build system set. At the minimum, the output might be suitable for a 
true embedded device, a small USB bootable device, etc. At some 
intermediate level, you'd see the minimal system necessary to 
self-host. At the higher end, there'd be full server or desktop systems 
based on the same technology. As I recall, part of what got in the way 
was the strict separation of building the build tools and building the 
target system. On the other hand, I remember a later trend toward 
treating the whole build as a cross-compile, allowing, in principle, 
any combination of host/target system. Is this right? I seem to recall 
that's when the project was bogging down....did that approach ever get 
finished?

-- The info in the package meta-data and the info needed by vcheck are 
not precisely in synch, and gar2vcheck was a quick hack, just getting 
close. If you wanted to actually use the output you'd really need to go 
through by hand and clean up the specs. Maybe we could include the 
vcheck configuration files on a per-package basis, so that gar would 
start with a valid vcheck description for the package, and if the 
upstream changed, the gar version could be updated by the package 
maintainer to reflect that.

-- You wouldn't want to automatically update gar to incorporate a new 
version of a package, just because it had been updated. Designing the 
interface so that package maintainers and other users could optionally 
build from the standard version or test with the newest would be 
helpful.

-- Gar, an improved garchive, CVS or alternative, and vcheck together 
get a large part of the way toward recording the state from which the 
system got built. Some of the info is transient, though. For instance, 
vcheck overwrites its own configuration file to reflect the newest 
version info it has retrieved. For my purposes, I'd want to make sure 
that historical info was recorded. Maybe it would be as simple as 
including the vcheck config files in the gar tree, and checking them in 
with all the other package description meta data after every check with 
vcheck, so that no version info would be lost. Or at another 
interval...? In any case, while getting enough data in the 
repository/archive to rebuild any version at any time is the biggest 
part, for my purposes even recovering descriptive historical data would 
be important to providing an "audit trail" of where the system came 
from.

-- I'm sure there are things I'm not thinking of ... and 
misremembering... any advice?

By the way...I'm kind of interested in virtualization, but not that 
familiar. Do you think there might be better alternatives to chroot, 
like Xen, or is that overkill?

Thanks for keeping this going....and for the feedback

Bill

On Thursday, February 16, 2006, at 08:05  AM, Paul Gray wrote:
> ... The one thing missing above, that I can
> envision, is the actual build environment in the form of a chroot.  As 
> building
> the lnx-bbc from sources can illustrate, the build environment comes 
> into play
> in the final deliverable too.
>
> We have some chroots for the ppc and i386 variants.  Is this something 
> you'd be
> interested in including?