[PC-BSD Dev] Dev Digest, Vol 62, Issue 8

Torsten Eichstädt 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 
best on-the-fly.

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, 
etc.pp.


> 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 
passent".

-- 
=|o)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/dev/attachments/20130309/f0680e94/attachment.html>


More information about the Dev mailing list