Tiny Core Linux
Off-Topic => Archive / Obsolete => SCM EXtensions => Topic started by: jls on April 30, 2012, 07:27:52 AM
-
I load gimp2-basic but gimp2-basic-locale
-
By defintion of scm there are no dependencies.
If you need the locale too then install/mount it.
-
is there any logic or need for separating locales
if it is self-contained modules?
this is logical if needed goal to reduce of scm size
but then need to load two pieces as a single composite module
in order to avoid losing logic of self-contained modules
this is not question and not assertion
it's just a thought out loud
-
By defintion of scm there are no dependencies.
this is not true, for example audacious-gtk2.scm dipends on gtk2.scm
-
We all know that is the one exception. We would not have it any other way. This has been discussed many times.
-
I think we could do the same way of TCZ, the locales.scm may depend on the program.scm, basically there are not other reasons for loading locales more than translating software in use, or not?
-
As for the -locale part of the extension, they are used by few. So some of the larger ones have been separated as to not punish the many with a larger download, and they are very easy to locate and load, no real need for adding them to dep files really.
I think a reasonable criteria is that if a locale pack is around 5mb compressed, and is over half the size of the main extension, then it makes sense to keep it separate. Otherwise it can just be included.
-
I think we could do the same way of TCZ, the locales.scm may depend on the program.scm, basically there are not other reasons for loading locales more than translating software in use, or not?
make tcz extensions are dependent from their locale was not very successful solution
this brings certain restrictions when removing extensions and those deps which are also dependent from locales
-
I have explained bad, I think it is right to separate locales, because doing so there are no contraindications.
However, if I need only load the application simply I does not load the translation, but if I need translated all I need to load only its locales with the right dependencies.
O.T. for the future you have any idea how to unify scm with the ondemand?
P.s. @ abnormis, hey man! I mean the locales dependent from the program not the program dependent from the locales! es:
scm-load -i program.scm charge only program
scm-load -i locales.scm charge program and locales
-
P.s. @ abnormis, hey man! I mean the locales dependent from the program not the program dependent from the locales! es:
scm-load -i program.scm charge only program
scm-load -i locales.scm charge program and locales
dear vinnie
just that i meant that it is not a successful solution
if change this then must in such way as it is implemented in tce-load by checking lang bootcode during extensions load
O.T. for the future you have any idea how to unify scm with the ondemand?
are you mean this topic (http://forum.tinycorelinux.net/index.php/topic,12960.0.html)?
-
Yes :P
-
it seems that is not enough to have an idea
necessary to have a ready-to-use solution ;)
-
I think that scm should still be well digested by comunity,
I do not even frame well the situation, so I prefer to listen in silence ;)
-
if option useless then it will be documented
if option is useful then it will be improved :D
-
propose to consider and testing changes in the script /usr/bin/scm-load
to be able download, install and uninstall scm locale with primary scm
modified script attached
mountpkg() {
if [ -f "$1".md5.txt ]; then
md5sum -c "$1".md5.txt >/dev/null
if [ "$?" != 0 ]; then
echo "Error on $EXTENSION"
abort
fi
fi
APP=`basename $1 .scm`
[ -d /apps/"$APP" ] || sudo mkdir -p /apps/"$APP"
sudo busybox mount "$1" /apps/"$APP" -t squashfs -o loop,ro,bs=4096
if [ "$?" == 0 ]; then
if [ "$LANG" != "C" ] && [ -f $APP-locale.scm ] && [ ! -d /apps/$APP-locale ]; then
if [ -f $APP-locale.scm.md5.txt ] && md5sum -c $APP-locale.scm.md5.txt >/dev/null; then
sudo mkdir -p /apps/$APP-locale
sudo busybox mount $APP-locale.scm /apps/$APP-locale -t squashfs -o loop,ro,bs=4096
else
echo "Error on $APP-locale.scm"
fi
fi
if [ "$(ls -A /apps/"$APP")" ]; then
if [ -x /apps/"$APP"/config/install ]; then
sudo /apps/"$APP"/config/install
fi
[ -d /usr/local/share/applications/ ] || sudo mkdir -p /usr/local/share/applications/
ls -A /apps/"$APP"/share/applications/*.desktop > /dev/null 2>&1 && \
sudo ln -s /apps/"$APP"/share/applications/*.desktop /usr/local/share/applications/ > /dev/null 2>&1
[ -d /usr/local/share/pixmaps/ ] || sudo mkdir -p /usr/local/share/pixmaps/
ls -A /apps/"$APP"/share/pixmaps/*.png > /dev/null 2>&1 && \
sudo ln -s /apps/"$APP"/share/pixmaps/*.png /usr/local/share/pixmaps/ > /dev/null 2>&1
if ls -A /apps/"$APP"/bin > /dev/null 2>&1 && ! grep "link_bin=no" /apps/"$APP"/config/spec > /dev/null 2>&1; then
sudo ln -s /apps/"$APP"/bin/* /apps/bin/ > /dev/null 2>&1
fi
if [ ! "$BOOTING" ]; then
desktop.sh "$APP"
[ $(which "$DESKTOP"_restart) ] && "$DESKTOP"_restart
[ -n "$ICONS" ] && "$ICONS".sh &
fi
fi
fi
}
fetch_app(){
echo "0" > /tmp/appserr
[ -f "$1".dep ] && [ ! -f "$EXTENSION" ] && rm -f "$DEPLIST"
wget -cq "$MIRROR"/"$1".dep 2>/dev/null
wget -cq "$MIRROR"/"$1".md5.txt 2>/dev/null
wget -c "$MIRROR"/"$1"
md5sum -c "$1".md5.txt
if [ "$?" != 0 ]; then
echo "Error on $EXTENSION"
abort
fi
SCMLOCALE=${1%.scm}-locale.scm
if [ "$LANG" != "C" ] && [ ! -f $SCMLOCALE ] && wget --spider -q $MIRROR/$SCMLOCALE >/dev/null 2>&1; then
wget -cq $MIRROR/$SCMLOCALE.md5.txt 2>/dev/null
wget -c $MIRROR/$SCMLOCALE
md5sum -c $SCMLOCALE.md5.txt || echo "Error on $SCMLOCALE"
fi
}
remove(){
FREEDESKTOPAPP=/usr/local/share/applications/"$APPNAME".desktop
MENUNAME="$(awk 'BEGIN{FS="="}{if ($1 == "Name") print $2}' "$FREEDESKTOPAPP")"
if [ "$LANG" != "C" ] && [ -d /apps/$APPNAME-locale ]; then
sudo umount -d /apps/$APPNAME-locale
sudo rmdir /apps/$APPNAME-locale
fi
# Remove menu item
read DESKTOP < /etc/sysconfig/desktop
[ $(which "$DESKTOP"_rmitem) ] && "$DESKTOP"_rmitem "$APPNAME"
[ $(which "$DESKTOP"_rmitem) ] && "$DESKTOP"_rmitem "$MENUNAME"
[ $(which "$DESKTOP"_restart) ] && "$DESKTOP"_restart
# Remove icon
if [ -n "$ICONS" ]; then
ICONSPEC="$(awk 'BEGIN{FS="="}{if ($1 == "X-FullPathIcon") print $2}' "$FREEDESKTOPAPP")"
[ -n "$ICONSPEC" ] && "$ICONS"_rm_icon "$MENUNAME" && "$ICONS".sh &
fi
for I in `find /apps/bin`; do
readlink "$I" | grep "/apps/$APPNAME/bin" > /dev/null 2>&1 && sudo rm "$I"
done
for I in `find /usr/local/share/applications`; do
readlink "$I" | grep "/apps/$APPNAME/share/applications" > /dev/null 2>&1 && sudo rm "$I"
done
for I in `find /usr/local/share/pixmaps`; do
readlink "$I" | grep "/apps/$APPNAME/share/pixmaps" > /dev/null 2>&1 && sudo rm "$I"
done
sudo umount -d /apps/"$APPNAME"
sudo rmdir /apps/"$APPNAME"
}
Removed attachment as it is against forum policy.
-
when i tested these changes i found some "features" at work with scm
1. if been downloaded and installed tcz extension then scm deps
with a similar names can't be downloaded and installed (for example gtk2)
2. scm are repeatedly added to scmboot.lst without their checking in this list
3. when deleting scm ( scmapps -> apps -> local -> delete -> go )
then its name are not deleted from scmboot.lst
4. and now the most interesting
when deleting an scm then will be deleted tcz extension with a similar name
for example tar.scm, tar-locale.scm etc (and yet i had installed abiword.tcz ;))
-
Removed attachment as it is against forum policy.
dear roberts
sorry, but i do not quite understand what exactly i violated from below mentioned
http://forum.tinycorelinux.net/index.php/topic,7738.0.html
http://forum.tinycorelinux.net/index.php/topic,5287.0.html
i proposed changes to the existing system script and expressed this on the forum
i marked amended and attached a modified script for testing
because i have not found anything other than ban attach binary extensions
attached script does not violate the integrity of the system or its operation
may i something incorrectly translated and not exactly understood?
please forgive me if i'm wrong but please explain this to me
-
The same respect affored to extension makers applies to base system fucntions.
You do not decide to take control of someone's extension. We do not want multiple varations of core system functions. Especailly when a discussion was ongooing. There are exising ways to solve wihtout hard coding.
Please show respect and do not post replacements for core functions.
Ideas, suggestions, and discussions are welcomed. Posted replacements of core functions especially as attachments are not. User posted replacments would become a support nightmare.
Please let myself and the team handle the core there are plenty of new requested extensions that you can contribute.
-
Back to the topic:
Many ways to handle. Some are quite easy. Note that not everyone needs a locale file.
In order of ease and least impact:
1. Add needed locale.scms to scmboot.lst (Easy)
2. Manually load locale when loading the base scm via ScmApps GUI. (Simple)
3. Create a .dep file for the locale.scm indicating the base scm name. (Less simple)
4. Embed every local.scm into the base scm extension. (Much larger downloads)
5. Hard code searching for a corresponding locale file for each and every extension install, uninstall, and deletion. ( Impacts every user and every action for every extension).
-
The same respect affored to extension makers applies to base system fucntions.
You do not decide to take control of someone's extension. We do not want multiple varations of core system functions. Especailly when a discussion was ongooing. There are exising ways to solve wihtout hard coding.
Please show respect and do not post replacements for core functions.
Ideas, suggestions, and discussions are welcomed. Posted replacements of core functions especially as attachments are not. User posted replacments would become a support nightmare.
Please let myself and the team handle the core there are plenty of new requested extensions that you can contribute.
with great respect roberts thanks for your explanation
in any case I did not mean disrespect of your work and team
i just tried little help in improving your unique like me think system
-
if there be accurate then going back to the topic title involves automatic loading locales
unfortunately none of the proposed first four decisions can't considered fully automated
but if already decided not to resort to hard coding then will have to use available means
thanks
-
Perhaps since scm extensions are usually downloaded once and put on hard storage, and their updates are small with the use of zsync, maybe it would be simplest and best to just include the locale files in the scm, keeping with the self contained concept as much as possible.
On looking at the locale situation, my vote is for simplicity of included files.
-
The team has discussed the scm locale situation and has opted for the simplicity of including the locale data in the scm. I will pack the files in the existing scm's, and any new ones will simply include them. Even the largest apps will rarely take over 5mb of compressed locale files, so the cost should not be significant.
-
do not you think that is very controversial decision was made?
if follow the tinycore principles of minimalism
then need separate the locale from main modules
because how to deal with such cases as these
gimp2-basic-locale.scm - 12.5MB
gimp2-basic.scm - 8.5MB
gtk2-locale.scm - 10.8M
gtk2.scm - 11.4M
gtk3-locale.scm - 10.5M
gtk3.scm - 9M
pidgin-minimal-locale.scm - 8.5M
pidgin-minimal.scm - 10.2M
it seems that such cases may be more than desired
when locales are the same or even larger than main modules
and purely english-speaking users are also not few
-
My initial motive for separating locale data was that they tend to be large, and are used by the minority. They are very easy for those who want them to load them and include them in scmboot.lst. Those who do not need them will never download or install them. For those who use them, once in scmboot.lst they are always loaded and available.
Locale extensions are very easy to find, easy to load, and easy to unload for those who need them. But as it apparently is not satisfactory to require loading -locale extensions and automation and thus complexity was desired, we opted for simplicity.
-
Hi AbNoRMiS
While one of the core principles behind Tinycore is a small footprint, the point behind an scm is to be self contained.
As a result, scms are larger anyway since they contain private copies of libraries that would normally be shared
between extensions. Personally I think it makes sense from a self contained point of view to include locales.
-
murphy was right: any solutions breeds a new problems
frankly if my wish then i would leave as is now, it would be the easiest solution
but i think after some time someone will offer question of locale automation again
i am sure in this because even before this topic was established
i would propose changes to automatic download, install and remove tcz locales
:)
-
It really is a shame that now someone is going to have to download and store a 20MB extension instead of an 8MB one in the case of gimp2-basic.scm. Or 22MB instead of 11MB in the case of gtk2.scm. All because one or two people were not satisfied with having to go through the effort of clicking "Install" in the Scmbrowser to install their needed locale extension data.
-
must confess that i been one of those three people
but then the other two diverged for some reason
:)
-
I spoke in a moment of frustration, it is not really that simple nor for that reason that we are going to include locales in the main scm extensions. Though sure, this thread sparked that debate, there were several issues to consider regarding loading, unloading, etc. .
Mostly, we don't want the scm to head down the slippery slope of feeling it needs to compete with the tcz in terms of modularity, size, etc, therefore diluting it's main goal of being self contained. Larger downloads are just part of that concept.
-
Mostly, we don't want the scm to head down the slippery slope of feeling it needs to compete with the tcz in terms of modularity, size, etc, therefore diluting it's main goal of being self contained. Larger downloads are just part of that concept.
Even before the decison on handling locales was taken, the basic concept of an scm means that the download size of the scm will often exceed the size of a tcz alternative. It is inherent within the design. Earlier posts seem to refer only to the compressed size of the download.
Upon installation to the file system, the app has to be uncompressed which results in RAM being used. Increasing the size by incorporating locale files will exacerbate this further. It may be particulary detrimental on older systems having smaller ammounts of RAM, or those with fixed amounts of RAM.
Might it be possible to accomodate the locale files within the scm while reducing the size used as described below. The idea is raw and unpolished and meant to outline the concept rather than represent a finished method.
The scm contains three distinct parts:
- app
- app-locale
- loading script
The loading script loads app and app-locale in separate stages:
- stage1 load app
- stage2 load app-locale
After stage1 but before stage2, the loading script checks for a marker file or variable which indicates whether to conduct stage2
The marker file or variable might be created by use of a checkbox, or similar means, in the TC scm management GUI
If the above is practical it will:
- allow the scm to contain locale files
- allow the user to choose whether to load them
- enable the system to manage the scm as a single entity
Edit: fix typo
-
Upon installation to the file system, the app has to be uncompressed which results in RAM being used. Increasing the size by incorporating locale files will exacerbate this further. It may be particulary detrimental on older systems having smaller ammounts of RAM, or those with fixed amounts of RAM.
I'm afraid this is wrong. The only RAM used is the squashfs cache, which is a couple ten kb per mount. It doesn't depend on the size of the squashfs archive.
(regular file cache is of course on top, but that one can be freed if needed; squashfs cache can't.)
-
Add dep in locales i think is the simpliest solution and package remain Light.
-
I'm afraid this is wrong.
My misunderstanding, thanks for the correction.
-
As I am totally unfamiliar with locale use, does having locales in share/locale in each scm even work in providing internationalization of each app without something exported in the app's wrapper in bin/? I am assuming it does, but thought I would ask for clarification.
-
With natively compiled apps, yes. Can't say whether it works with the binary-hacked ones (././).
-
I added ripperx-locale.tcz to the ripperx.scm extension, and it does work with "LANG=it_IT /apps/bin/ripperX", so the portable apps work with locales as well when the locale data is available and added to the scm extension.
-
i downloaded and installed ripperx.scm
but did not find there locale files
but i found the remains of tcz extensions
/apps/ripperx/local/tce.installed/shared-mime-info
/apps/ripperx/local/tce.installed/gtk2
/apps/ripperx/local/tce.installed/gdk-pixbuf2
-
/apps/ripperx/local/share/locale
The other files are small and harmless, I'll deal with them next time I have to edit the extension.
-
tc@box:~$ find /apps/ripperx -name "locale"
tc@box:~$
there is nothing
-
I see I tested it but forgot to upload it, will upload it tonight.
-
Actually, the startup scripts in tce.installed usually need to be run or at least studied to see what needs to be done in initially setting up the extension. So they are valuable to keep in the scm, as the tcz packages it was made from may get updated and their startup scripts changed, leaving no record of what was done in making the scm or what may have been missed and needs to be done in the case of troubleshooting an issue. Best then to leave them in, they are small anyway.
-
Add dep in locales i think is the simpliest solution and package remain Light.
dear vinnie
i lit up a little improved idea which i have outlined here (http://forum.tinycorelinux.net/index.php/topic,13208.0.html)
which also may be applied to self-contained modules
-
Actually, the startup scripts in tce.installed usually need to be run or at least studied to see what needs to be done in initially setting up the extension. So they are valuable to keep in the scm, as the tcz packages it was made from may get updated and their startup scripts changed, leaving no record of what was done in making the scm or what may have been missed and needs to be done in the case of troubleshooting an issue. Best then to leave them in, they are small anyway.
i think need move the contents of these startup scripts to /apps/scm_name/config/install
-
That would only be needed if there was a function that needs to be run every time the extension is loaded, which so far is not that case. But for something that is needed to be run every time the extension is loaded, then yes, the routines would be put in the scm's startup script.
-
Moderators
I feel this post needs to be a sticky at page one as well please.