Off-Topic > SCM Extension Requests

GTK2 Enhancement Request

<< < (2/3) > >>

AmatCoder:
Ok, I see...thanks for that.

Another case could be gschemas.compiled under ../share/glib-2.0/schemas/
That is used by applications that saved settings using GConf or dconf (gsettings).
glib-compile-schemas is the command that generate it.

Jason W:
Ok.  So far three commands and resulting data directories that are to be dynamic to accommodate various apps that will use gtk2.scm.  As well as some of that data residing in the directory of the app itself.  This is of course the down side to having a separate gtk2.scm extension.  And I will make adjustments for those commands to be used and the data to be generated.

A separate gtk2 means faster startup and less RAM used, but with the above complications.  Including gtk2 in an app directory means any needed data aside from fontconfig files can be static as it can be generated once and is not needed by any other programs.    Midori has apparently been broken by an update to gtk2.scm, breaking extensions is another risk with the separate gtk2.  I will fix and support gtk2.scm but I admit that I am beginning to lean toward a more fully self contained approach for stuff that I package.

Rich:
Hi Jason W
I'm, probably just stating the obvious but, as I understand it, the point of SCMs was the ability to easily mount and
unmount extensions at will and eliminate extension breakage due to dependency updates. The price for this being
larger packages, longer downloads, and greater disk and RAM requirements by the user. The other price that comes
to mind is if one of the built in dependencies needs an update, say for a security fix, then all the SCMs using that
built in dependency may need to be rebuilt. For all practical purposes, a tcz is just the opposite.

While I understand your desire to create an SCM architecture that is the best it can be, this hybrid approach sounds
like you are fighting two conflicting goals in an attempt to get the best of both worlds. That only works if the package
styles share a common attribute you can leverage, which doesn't sound like the case.

Kind of reminds me of a car commercial I once saw that claimed "exhilarating acceleration" and "phenomenal gas
mileage". The two don't co-exist in reality.

In any case, just some thoughts on my part and thanks for all of your contributions.

SamK:

--- Quote from: Rich on February 27, 2013, 12:19:29 PM ---...greater disk and RAM requirements by the user.
--- End quote ---
This sparked a recall of a comparison done shortly after the introduction of SCMs.
http://forum.tinycorelinux.net/index.php/topic,12457.msg67531.html#msg67531
When used from persistent TCE storage, greater RAM usage seems to be more of a theoretical than practical issue.  I have not studied the matter to a great extent, but where SCMs have been adopted here, there has not been a noticable increase in RAM usage or an observed deterioration in perfromance as a result.



--- Quote from: Jason W on February 27, 2013, 10:23:56 AM ---A separate gtk2 means faster startup and less RAM used...
...breaking extensions is another risk with the separate gtk2.
...I am beginning to lean toward a more fully self contained approach for stuff that I package.
--- End quote ---
For me, the principal attraction of the SCM format is its resistance to breakage.  If that resistance can be improved, without a corresponding increase in the RAM required, it will be at least worth exploring. 

Jason W:
At this point I agree that the middle of the road approach is making the SCM less valuable than going "whole hog" and leveraging the advantages of total self containment.  If we are dealing with one scm being broken by an update of another, like in the case of Midori, then we have lost the "just works every time" advantage of the SCM.  Also if commands are needed to be run inside the package of one SCM, like gtk2.scm, to make another one like rox-filer.scm work, we lost the advantage of less complexity. 

I have started experimenting with fully self contained SCMS in the last week or so, and to be honest I was expecting criticism of it based on the RAM and download/storage space angle.  Of course, optional large packages like python and perl can remain just that.  I am glad that the current seems to be to go ahead and just make SCMs outright and not try to stay in the middle of the road to please all.  Those that don't use SCMs are not going to use them whether they are factored and more efficient or if they are not, so why water down the concept. 

The totally self contained packages made of recent are a test of concept and are likely not the final road to be taken in terms of internal structure or source, and of course all input is welcome.

Navigation

[0] Message Index

[#] Next page

[*] Previous page