[PC-BSD Dev] Dev Digest, Vol 62, Issue 8
torsten.eichstaedt at web.de
Sat Mar 9 12:53:28 PST 2013
Am Samstag, 9. März 2013, 11:36:28 schrieb Kris Moore:
> > 2. Change the configuration data files to a standardized,
> > human-readable and simple data format. My suggestions are YAML or JSON.
> Sounds good! Is this something you personally are offering to write?
Well, I think you know all this and it's the standard way the work in PC-BSD
is done anyway, n'est pas?
I'd propose to
1st move the data file's syntax over to a better data format, while keeping
the sh-scripts, but fix these to use available sh-libraries for data access,
2nd re-write and refactor the sh-scripts to a better scripting language.
I propose to evalute the existing sh-libraries to handle YAML and JSON, and
which one of YAML and JSON fits better to PC-BSD's needs.
First step, sort the cfg scripts by their importance concerning system
security & stability. Of those with the lowest risk, pick one that is
read/written by the fewest sh-scripts. This should be fairly easy, and could
be done in the wiki.
Then it's time for the 1st spike solution:
Invent and create systematic tests concerning this special cfg data file.
Keep focus here. Write down ideas for more general tests, functions, etc.
e.g. in the wiki, but keep focus on only this one file and it's domain. KISS.
Create a jail to supply the test environment, or another idea could be that
it's simple to switch between the test-system and your real one by simply
mounting relevant FS. We're starting with a low-risk cfg file, so one might
be curious enough to test in a live system.
Rewrite the data file to YAML/JSON (pick one). Should be fairly easy.
Adjust the script(s) to use the library functions to read and write the
changed data file.
Run the tests. Fix bugs, refine & refactor the tests. Check the trac bug
database. If a bug listed there gets fixed by simply using the library for
cfg data access, we have a hint. Drop a note in trac and the wiki.
Repeat this step for the other data format.
Document all steps in the wiki, pitfalls, ideas for generalisations, etc., at
Repeat these steps for the next cfg files (re-use the test-jail), naturally
then more general tests will be developed (but: KISS), until you know enough
how to proceed. I.e. the whole idea was bulshit, or the sh-libraries are
cramp, or it's the right direction, which one of YAML/JSON fits better,
> If you can write a better installer, then by all means go forward! If
> we plan on making this specific / unique to PC-BSD, then it gives us
> options as to different languages/interpreters/libraries, etc. The
> reason I wrote pc-sysinstall in shell originally was that we needed
> something that would work in "vanilla" FreeBSD. (And between C / shell,
> I preferred shell). Since FreeBSD has been going forward on their own
> BSDInstall for a while now, then I think its safe for us to move on to
> something better. How are you planing on doing the integration with
> gpart / zfs, command-line or using libgeom and friends?
The steps I suggested above will fix the most urgent bugs in the installer "en
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev