Off-Topic > Release Candidate Testing

microcore_v2.10rc1

<< < (3/4) > >>

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, ...

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version