I'm working on a solution to the problem of how to manage the efsdeploy
configuration information, hooks, patches, etc.
Right now, we're not putting this information into source code control
ANYWHERE. Not in EFS 2 land, not in EFS 3, nowhere. This isn't such a
major problem because the /efs/dev namespace effectively versionizes this
stuff everytime you checkpoint a new release, but it's a problem because
we're not sharing this information, and we're not tracking ANY of the
changes anywhere.
I'm got about 5 pages of notes I made on how to tackle this and a solution
is starting to form in my mind. The basic idea is that each project will
have it's own git repo, and efsdeploy will be enhanced to know how to talk
to it, very basically. In order to start playing around with the idea, and
experimenting with automation for it, I need to create a few new git repos
on openefs.org.
The convention I'm currently considering is:
git://git.openefs.org/efs-deploy-config-$metaproj-$project.git
Then efsdeploy will get some new commands, for example:
scminit
scmpull
scmpush
For metaproj's like gnu, where we install each project by hand, this
approach will work pretty well. For one's llke perl5, where most of the
projects are created automatically by cpan2efs, I don't want to require a
git repo, since in the overwhelming majority of cases, installation is 100%
automated now. We're almost to the point where even some gnu projects can
be installed with NO config (if we supported a default download->url for
gnu/tar, not even efsdeploy.conf is necessary).
This has become a higher priority issue because of the changes I have
recently made to gnu/gcc's build scripts. I want to make sure we have this
critical information available, and right now, it's not.
Jerry -- can you create the above repo for me for gnu/gcc, and document how
it's done, so we can automate it? I have some reservations about the git
repo namespace growing linearly this way, so this is NOT a final design, but
merely an experiment for a proof of concept. Once I have a basic workflow
functioning, I want to write it up and get a discussion going (if possible
-- this is one of the lowest volume mailing lists in the history of the
Internet) about how to generalize the solution.
Without a good solution to this, anyone bootstrapping an EFS 3 domain will
have to struggle with ALL the same issues that are solved in the currently
unavailable gnu/gcc rules, among other things. This is the missing piece of
the puzzle for complete reproducibility of an EFS domain.
_______________________________________________
EFS-dev mailing list
[email protected]
http://mailman.openefs.org/mailman/listinfo/efs-dev
