Hi Apmuthu
There is redundancy in the package which should be removed but we've never gotten 'round to it. For example, you mention DBSQL, lineIOdump and startDBSQL, none of which are used. They really should be removed.
The system uses a more or less, pristine database, which is called
sarkstart.db. During an install or upgrade, the installer looks to see if sark.db exists. If it doesn't then it copies startsark.db to sark.db. Next, whether install or upgrade, we run a script which applies all of the sql fragments in
/opt/sark/amacs in name sequence. The name is made up of a letter plus the svn commit number, so it's effectively applied in ascending time order. There is redundancy in the fragments but by and large it doesn't matter. The process relies on the natural entity integrity of the database for its idempotency. In other words pretty much everything it does is additive so a re-run will simply cause a lot of harmless errors because the row(s) will already exist. It's not pretty but it's not bad and in theory it allows upgrade over any jump in release although I can't categorically rule out any corner cases.
I keep visiting the idea of drawing a line under the process and starting again but that would mean an absolute barrier to upgrade which would demand some kind of migrate. On balance I think it is OK and we've used it throughout V3/V4.
We have 2 releases which we currently focus on; 3.1.1 and 4.0.0. 3.1.1 is effectively stable. We aren't actively adding features to it any more, we just bug fix.
SARK integration with SME was deliberately loosened, beginning with V3. This hasn't anything to do with our commitment to SME but is down to the fact that we run SARK on other platforms and CPUs where SME cannot run. We have versions running on PPC and ARM (5 & 6). By and large the central code is identical across all platforms. However, each platform has its own environment pack, which in the case of SME is called smesailenv. We already have a version for Squeeze which we run on the S200 and Raspi (just for fun) but there are no plans to make a general Debian release at the moment.
We plan to move the source to GiT and make it generally available but we just haven't gotten 'round to it yet.
I promise I will visit all of the redundancies you've pointed out before too long.
Kind Regards and thanks again
S