dCore Import Debian Packages to Mountable SCE extensions > dCore X86

various thoughs & questions

<< < (2/3) > >>

Jason W:
Centralware -

When dCore started, it was the first Tinycore push into Armv7.  That is not a big deal to me but you wondered why choose dCore armv7 when there was Core armv7.

Also, the Nasa blog that mentions using Tinycore for a project -

https://modelingguru.nasa.gov/community/atmospheric/boinc/blog/2009/10/13/modele-on-tiny-core-linux

It is the first search result when Googling the terms "tinycore nasa". 

Jason W:
Some good suggestions were brought up in this thread, and they are now implemented in release candidates.

To summarize:
Updated SCEs now moved during shutdown.

Reverse tree update of SCEs that have dep files, whether updating the whole SCE directory at once or one at a time.

Checking against an SCE that exists in the update dir rather than in the TCE dir - both for updatesce functions as well as importing and using that SCE as a dep.  The update function actually already did that as I looked at the code, but now they both do.

The only thing left is to make updatesce recognize if the tree of dep files provide the needed package dependencies of an SCE.  The needed data is stored in each SCE, I will tackle that next but for now the other things are in release_candidates to be tested.  That, and for a script to show the dep tree of an SCE which is info that can be nice to know.

Jason W:
Editing a dep file or re-importing an SCE using the -d dependency option and choosing a different set of deps as the first should now result in the SCEs that depend on that one to need an update when updatesce is run.

IOW, say desktop.sce depends on xorg.sce which depends on base.sce.  Now changing base.sce.dep from containing "mc" to "mc1" or nothing or "file" will result in both desktop.sce and xorg.sce reporting needs for updates. Uploaded to release candidates.

Jason W:
Centralware -

I see I missed the gist of your question.  And very interesting that you worked at NASA!  I work in a factory myself.  :-) To more accurately answer your question, the idea is to be as little as possible difference between Core and dCore, especially in user experience, besides the source of the packages.  And that yes, dCore was initially focused on porting dCore to other architectures, initially ARM.  I hope one day to be able to have the time and hardware to put more focus there.

JW

Jason W:
And thanks JLS for bringing these ideas and bug reports to my attention. 

Navigation

[0] Message Index

[#] Next page

[*] Previous page