V.Krishn -
It sounds like that method is basically like combining tcz's into one extension, thus eliminating having to call on dependencies, and then linking them into the shared system just like the tcz.
One issue with that is that it would cause library file conflicts since various versions of the same library, built perhaps with different options, would be in /usr/local/lib. And also the main purpose of the scm is to have a clean mount/unmount that does not install/symlink files into the system, therefore not causing any file or library conflicts. At least not outside of the .desktop and icon files in /usr/local/share that get linked to the system.
####
Bmarkus in the release candidate thread mentioned the existence of dependencies in the scm's in regards to their effect on the self contained format. Here is my view, that scm's can be as dependent or not dependent on other extensions that the extension maker deems fit. I first was including gtk2 into each gtk2 app like leafpad, but that does result in about 7mb of ram being occupied when each different scm gtk2 related app is launched. And also the time of building gtk2 over and over for each app. Thus the existence of gtk2.scm and gtk3.scm. And maybe one day qt4.scm. To me that is a good middle ground to ease the memory requirement of scm's. And Xorg-7.6-lib is called on as a dep instead of building parts of Xorg into each extension, though those libs could be placed in the scm's lib/ path to not need that dependency. Up to the extension maker as we already host the source for Xorg.
There is a trade off between total self containment and extension size and resource use. One can even use the gtk2.tcz and it's deps for an scm dependency, but the more dependencies you add the less benefit of being self contained. But again, it would be up to each extension maker, there is not a hard and fast rule. Me, I aim for three or less dependencies to keep it simple - Xorg libs, gtk2/gtk3/qt, and perhaps python or similar. Smaller stuff gets built into the scm.
I mentioned about making scm's out of tcz's, and I have done that for avidemux, it needs no deps but either OSS or alsa at the user's choice. It is basically a test concept that could save a bit of work by using tips from portablelinuxapps.org. The source is already hosted, no having to rebuild. There are some snags I have run in to, and I don't know how far I will try to go down that path, but it is kind of neat to play with. I will of course troubleshoot any issues with the converted scm's, and anyone let me know if they have issue with me making a self contained app out of their build. But for those apps that convert cleanly and work without issue, it is of great help to be able to use them.
Anyway, not to ramble too much, but that is where things are at now. I think I am taking a sensible road in regards to structure and dependencies, etc, and I am open to any ideas.