Tiny Core Extensions > TCE Talk
Adverse Effect of Change to dbus Extention
SamK:
Having applied the most recent update of dbus.tgz, two apps fail to start (Firefox and File-Roller). Both apps were working entirely satisfactorily before the update. To resolve the issue the previous version of dbus has been restored.
The current version of dbus requires that it is started manually, where the previous version started automatically. This gives rise to the following questions and observations:
Outwardly, this change 'breaks' an otherwise working system. Would it not be preferable to explicitly seek the end user's agreement before doing this?
Is it not possible (during installation) to ask the user if automatic starting is to be retained?
When an app is not explicitly requested to be installed, but is added as a dependency, might it be reasonable to assume that it is required to be started in order to allow the parent app to function.
This appears to be a retrograde step in terms of the usability of TC in that both experienced and inexperienced users now have to realize that a dependent has to be manually started or added to a script in order to continue to use their apps.
I would favour a default of being automatically started with the ability to deactivate (onboot?). This will allow advanced users the management/control they may require, while being more friendly to the less advanced user.
Juanito:
Several users have said that they want daemons to be started when an extension is loaded and several users have have said that they do not want daemons to be started when an extension is loaded.
Rather than use an earlier version of the dbus extension, you can add a line to bootlocal.sh to start dbus, or other daemons on boot.
Thought is being given on how to handle this matter to most users satisfaction - as an example, having an extension auto-start a daemon on loading gave problems with recursive dependencies in some circumstances.
Jason W:
I have been one to push for the use of init.d scripts to start daemons to give the user control over what processes are running. And our true recursive dep loading does not allow the use of the tce.installed startup script to start daemons like dbus.
We simply need a way to have extensions autostart their init.d scripts if desired. I have several ways in mind. I will take the blame for this not so smooth transition as I have pushed for the use of init.d scripts to start daemons with.
gerald_clark:
Jason,
Until something better comes up, here is what I use to manage services.
I use a file /etc/services/.lst that lists services to run in the order desired.
I use "/opt/services start" to start the services, and "/opt/services stop" to
stop them in the reverse order.
I add "/opt/services start" to bootlocal.sh, and "/opt/services stop" to shutdown.sh.
--- Code: ---# services
# Start/Stop services
# Read service list from /opt/.services
# services start starts services in the order listed
# services stop stops services in reverse order
#
SERVICE_LST=/opt/services.lst
SERVICE_RUN=/tmp/services.run
if [ "$1" == "start" ] ; then
rm -rf $SERVICE_RUN
mkdir -p $SERVICE_RUN 2>/dev/null
grep -v "^#" $SERVICE_LST | while read PROG
do
echo "$PROG start"
$PROG start
echo $PROG > $SERVICE_RUN/${PROG##*/}
sleep 1
done
elif [ "$1" == "stop" ] ; then
ls -ctr $SERVICE_RUN | while read PROGNAME
do
PROG=`cat $SERVICE_RUN/$PROGNAME`
echo "$PROG stop"
$PROG stop
done
elif [ "$1" == "list" ] ; then
cat $SERVICE_RUN/*
else
echo "$0 : Invalid option $1"
echo "$0 start/stop/list"
fi
--- End code ---
--- Code: ---# services.lst
/usr/local/etc/init.d/nfs-client
/usr/local/etc/init.d/alsasound
/usr/local/etc/init.d/nfs-server
--- End code ---
SamK:
--- Quote from: Juanito on February 06, 2010, 09:20:48 AM ---Rather than use an earlier version of the dbus extension, you can add a line to bootlocal.sh to start dbus, or other daemons on boot.
--- End quote ---
Thanks for this suggestion - it had also been made during discussions in the irc channel. It does, however, re-emphasise one of the the points I made previously. It is a workable solution to the issue but is a rather obscure requirement to fulfill in order to conduct a simple task of running Firefox. Doing this may not be questioned by TC veterans but may well defeat newcomers to the distro.
I decided to post in this section of the forum as the matter is due to an extension. I wondered if it should have been posted in a different section as the effect is in my view, detrimental to TC (the distro) rather than just the particular extension.
From the perspective of someone new to TC being unable to install and run a widely used browser without research and editing of the underlying files is likely to have a detrimental effect on the appeal and take-up of TC.
--- Quote from: Juanito ---Thought is being given on how to handle this matter...
--- End quote ---
--- Quote from: Jason W ---We simply need a way to have extensions autostart their init.d scripts if desired. I have several ways in mind.
--- End quote ---
This is encouraging to learn. Without being in any way contentious, might it be worthwhile delaying the dbus and similar changes until this has been introduced. If not, it might be polite to explicitly obtain the users agreement and offer an option to decline the update. Once the autostart system has been resolved the warning could be removed and the update applied at that time.
Navigation
[0] Message Index
[#] Next page
Go to full version