microcore_v2.10rc1

[roberts]

The First Release Candidate of Micro Core v2.10 (microcore_2.10rc1.iso), is now posted and ready for testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/2.x/release_candidates/microcore/

microcore_2.10rc1.iso
microcore_2.10rc1.iso.md5.txt

Change Log for Micro Core v2.10

* Updated tce-load - much improved recursion support.
* Added missing rule for mmc support.
* Updated tc-config PXE tftp http for onboot.lst support.
* Updated tce-audit to download dep to /tmp then move to tce dir.
* Removed unneeded libthread_db* from base.

Updated Xprogs.gz with all the changes as listed for Tiny Core v2.10rc1 see:
http://forum.tinycorelinux.net/index.php?topic=5310.0

[Juanito]

Using appbrowser to load local, I like that you just need to double-click on an extension and it's loaded - no more clicking on "OK" afterwards 

Starting with no backup (and also with "base norestore") I only get a black background with Xvesa.

.setbackground does not exist in /home/tc - copying it from /etc/skel results in a seg fault when I try to run it.

[roberts]

base norestore on microcore would imply no window manager as no extensiona are being loaded therefore a black screen. Might try to manually load flwm & wbar extensions?

[Juanito]

base norestore on microcore would imply no window manager as no extensiona are being loaded therefore a black screen. Might try to manually load flwm & wbar extensions?

Sorry - I should have said I tried two ways:

"base norestore" then "tce-setup"
normal boot loading extensions and X*gz from tce, but with no backup being restored

[roberts]

Got it! Thanks. Fixed in rc2.

[Juanito]

Are we looking to have recursive deps load extensions in the order listed in the dep file as per "standard" deps?

If we assume for a moment that the avahi or dbus extensions try to start the dbus daemon from the start-up script (they no longer do this, but just for the sake of an example) and load rhythmbox using a recursive dep file, then the load order is:

avahi
dbus
expat2

..which means it wouldn't work.

Code: [Select]

$ cat rhythmbox.dep
totem-pl-parser.tcz
gnome-media.tcz
libsoup-gnome.tcz
gst-plugins-good.tcz
gst-plugins-bad.tcz
gst-plugins-ugly.tcz
gst-python.tcz
gmime.tcz
pygtk.tcz
pyorbit.tcz
gnome-python.tcz
libnotify.tcz
libgpod.tcz
gnome-icon-theme.tcz
shared-mime-info.tcz


[bmarkus]

As far as I know startup scripts executed after all extensions are loaded in alphabetic order. Maybe I'm wrong...

[Juanito]

Here's what I see when testing:

Code: [Select]

$ tce-load -i /mnt/sda1/tmp/rhythmbox_rec/rhythmbox.tcz
shared-mime-info.tcz OK.
gnome-icon-theme.tcz OK.
libgpod.tcz OK.
libnotify.tcz OK.
popt.tcz OK.
libbonobo.tcz OK.
audiofile.tcz OK.
esound.tcz OK.
gamin.tcz OK.
udevadm.tcz OK.
libusb.tcz OK.
usb-utils.tcz OK.
libpci.tcz OK.
pci-utils.tcz OK.
hal.tcz OK.
nss-mdns.tcz OK.
libdaemon.tcz OK.
gcc_libs.tcz OK.
/usr/local/tce.installed/avahi: line 14: dbus-daemon: not found
avahi-daemon: error while loading shared libraries: libexpat.so.1: cannot open shared object file: No such file or directory
avahi.tcz OK.
gnome-vfs.tcz OK.
...
dbus.tcz OK.
...
expat2.tcz OK.
...
rhythmbox.tcz OK.
again, I modified avahi to attempt to start dbus for the sake of testing

[roberts]

I would be happy to look at a tarball of your test case, perhaps if posted bmarkus and myself could look at it. However avahi should not be a dependency of rythmbox. Look at Debian, avahi is a recommends. Additionally startup scripts should be for extensions and not embedded within the dependency chain. The dependecny chain is recusred in order load all reuired files needed by the requested extension. The requested extension is always loaded last, and therefore its startup script should be successful.

[roberts]

To explain more look at:
http://packages.debian.org/sid/rhythmbox
and
http://packages.debian.org/sid/avahi-daemon
It would seem therefore they are separate and both would require a dependency chain that would be necessary, (and which happens to have many dependencies in common), for their startup script to be successful.

I would need to see a tarball(s) in order to more fully understand what is being attempted.

[Jason W]

I have also tested various extensions and noticed that with the current RC recursion method, and noticed startup scripts in the dependency chain that depend on either their deps to be loaded or their deps' startup scripts to be run may not work.  Since duplicates are not echoed into /tmp/deplist, an existing listing of expat will be lower in the list than some deps that need expat loaded for its startup script to function instead of it being echoed again above the extension that needs it. 

We currently with simple dep files support startup scripts that require either their deps to be loaded or the startup scripts of their deps to be run, whether during boot or appbrowser use.  And since the simple dep files determine the order of loading, startup scripts in the dependency chain are also supported.

What this means for extensions is that each dep file needs to contain all the needed functions for it to work, including any needed startup functions of its dependencies.  Instead of depending on a dependency to run it's startup script first. 

No big deal, but it is to be noted as a change in startup script behavior. 

[bmarkus]

I didn't check actual code, but I think this is  simple.

Extension loading and startup script execution are two different thing and must be separated.

First, ALL extensions must be loaded. Order is not important, it may happen in any sequence, depending on definition order, recursion method, etc. Don't care.

Next, when all extensions are loaded, startup scripts are executed. At this point can't be missing extensions, so startup scripts must work. The only issue is their execution order. Easiest way is alphabetic order. There are two prerequists:

1) An extension is allowed to install a startup script with any name independently of extensions name

2) There must be a cooperation between extension maintainers and core team to  keep it working.

[Jason W]

Running all startup scripts after all deps and extension is loaded would work as far as the needed dependencies being loaded, but as you said it wouldn't control order of loading. 

But one thing I ask to be tested.  And that is not suppressing duplicate entries in /tmp/deplist during the recursive scan routine.  In my testing it has produced dep-first loading and startup script execution that would support things like the rhythmbox example.  I could be wrong, but I think it is worth a try.

[roberts]

I don't think duplicates are helpful, as once loaded any duplicate is ignored.
Order is defined by recursion as added to deplist in 'stack' order. If any extension has a startup script then that script should be satisfied if its own .dep (list of dependencices required of its startup script) is loaded, which is currently the default. It will be most helpful if test case data is supplied.

[bmarkus]

For sure there are different solutions. However separation of loading and startup execution into two phases makes it more transparent and simple. Also it is much closer to usual persistent installation where no loading, everything is there.

Coordination is not a problem. First, there is a limited number of extension makers. Second, there can be ranges defind for system processes, like dbus, hal, etc. and for user level applications and for other necessary startartup levels. It would reduce risk for simple applications to mismatch system.

BTW, there are cases where a shutdown script would be necessary .

All together this would be a similar to the traditional redhat-like startup within a single run level. It works, flexible, ...