Re: gar2vcheck

I have some concerns about the gar2vcheck thing, maybe someone can
address them...

How do we handle the following:
sourceforge (the current bane of my existence)

websites that have been hijacked and now send you a garbage file of
the version that you request

people who have changed their versioning scheme

also is there a way we could go through and check for new / changed
dependencies?  (of course this would involve changing the makefiles to
include minimum version #'s of the depends, maybe on a comment line?)

And if we do try to do all this automation are we going to have
'verified' versions of the garchive that we know will build (at least
1 person from the devel team has gotten it to build w/o much trouble)
and 'use at your own risk' versions that someone can use if they want
an update we haven't 'verified' yet?

Also, am i detecting a want to fork this in to a 'bbc sized' build and
a 'how ever big you want' build?  Or is this just a user option to put
out there for the automated builds?

And as an aside... this is probably a conversation that should be on
the devel list... but maybe I'm just picky...

--ME

On 2/17/06, William Immerman <[email protected]> wrote:
> 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?
>
> _______________________________________________
> lnx-bbc mailing list
> [email protected]
> http://zork.net/mailman/listinfo/lnx-bbc
>
>


--
irc.slashnet.org #lnx-bbc

http://www.urbandictionary.com/define.php?term=3Dirc

random quote(s) for the week
http://bash.org/?75154

truth is rarely appreciated:
http://www.laddertheory.com/