Wiki tentatively complete

[sm8ps]

I have completed my proposed work for the wiki with the extensions page. As predicted, I got it done by the end of the month; luckily I do not remember which one exactly I had been talking about.  I would be glad if you all could look it over because I certainly learned a lot about extensions and so I may have missed one point or an other.

Furthermore, I have polished the entire set of pages so that they hopefully are easy to navigate through. When I find time, I shall want to add a page about the new ISO installation but that will not happen very soon. Maybe somebody else will beat me before the finishing line (maybe even you!). It is exciting to see how dCore comes along!

I think it is time now to "publish" the dcore-section of the wiki more openly. Specifially, I suggest adding the dcore:welcome-page to the navigation panel but this has to be done by a moderator. However, I have not been successful in contacting that person. Can anybody help?

[sm8ps]

While writing about extensions, I explored and learned a lot. In the course of this process, I stepped over some technical questions:

1. ) What is the logic behind sce-import asking to select a deb-package among list when the very same package is in the list? E.g. sce-import libphonon4 gives

Code: [Select]

Select Package for libpulse-mainloop-glib0_4.0-0ubuntu11_i386.deb
(...)
26. libpulse-mainloop-glib0_4.0-0ubuntu11_i386.deb
(...)among dozens of other candidates. That is the exact package so why do I need to select it? Which other packages would fit and how can I know?

2.) What are the data.extensions for (-data.tar.gz)? I see .deb-packages, prebuilt tar.gz extensions from the Tinycore repository and -data.tar.gz files in my tce/sce/ directory. How do they relate?

3.) What is the tce/import/ directory for? I see some sub-directories but cannot make out any specific logic. Ditto for '/tce/sce/update/'.

4.) I learned that the deb2sce files  under /usr/local/tce.installed/ are dCore-specific start scripts. Is it possible to browse the repository they come from so as to get an over-view?

5.) What about the memory consumption of mounted SquashFS? Is the full file un-packed in RAM or only the used files/blocks? That is crucial for the urge to create dependencies among extensions in order to keep their size small. I hit Google search with any kind of search phrase I could imagine but could not find anything.

6.) sce-load calls 'depmod -a' but that command is not available (on my system at least). Is this a problem in general?

7.) What is the difference of the two files .installed and .debinstalled under /tmp?

Thanks for your consideration!

[Jason W]

Hi.

1.  What you saw there is what happens when the Debian or Ubuntu Packages list is updated ahead of ours.  Does not happen often, but it can.  That menu comes up when the filename from our DEBINX is not found, that is has been updated and Debian always changes their deb file names upon any updates.

2.  Data extensions are extra files the package needs or benefits from to operate.  The Core specific things that make the window managers work are in the data.tar.gz files.

3.  tce/import is for downloaded debs and the working area of sce-import.  sce/update is for updated extensions that get coped over on reboot.

4.  Those startup scripts are created by us as needed, there is no upstream.

5.  Mounted squashfs takes very little ram at all.  Symlinking takes some, but nothing like what copying to filesystem would take.  i have 1.7GB of squashfs SCEs mounted, uncompressed to file system that would be about twice that or more.  But I can sit at a command prompt with all that installed and just 286MB of used RAM.  A huge savings, and this is the same as with Core and it's TCZ mounted extensions. 

6.  If depmod command was not available,  then any new kernel modules installed would not be usable, so I am quite sure you have it.

7.  /tmp/.installed is for already run startup scripts, /tmp/.debinstalled is for already installed deb or custom packages.  Not really meant to be directly used by the user under normal circumstances.

Hope this helps.

[sm8ps]

Thanks for your extensive answers! They do make things more clear but I still have a few that I do not quite understand.

1. Do the package lists not get fetched directly from the Ubuntu/Debian repos? What other ("ours") is there in play? If the debinx.-files come from the Core-repos then how are repos under debextra handled?

2.&4. Is there a URL where one can look at these files ans scripts? I have been unsuccessful trying so.

6. You are right, depmod is available, of course. What I meant (but did not read out of my notes) is that depmod -h does not show the option -a. Presumably it does work nevertheless.

[Jason W]

Our DEBINX files are in the link below, we have our own as we prune them to speed up searching that large file.

http://tinycorelinux.net/dCore/x86/

Below is the startup scripts and data files:

http://tinycorelinux.net/dCore/x86/import/

http://tinycorelinux.net/dCore/import/


depmod -a is the default behavior, the -a switch does not error even though no longer needed a current option since they apparently have that option grandfathered in as to not break scripts like ours.

[sm8ps]

Many thanks for the pointers! I remember having gotten there once but it is good to have this information in the wiki for future reference.

Regarding the DEBINX-files, how about including the secondary Ubuntu repos (universe, multiverse, restricted, canonical_partner) also in the Core repos? They are pretty much standard for Ubuntu and if it helps speed up the searching this might be useful to many users.

[Jason W]

I already combing the main, universe, multiverse, and restricted into one DEBINX file.  Hence another reason we use our own DEBINX.  I guess I can add the canonocal_partner too.

I can do this as long as there are no duplicate package names in the debinx files being combined.  That's why I can't do this with the Debian security or backports.

[sm8ps]

OK, great! This is valuable information to include in the wiki. -- So this means that there is no need to specifically include those repos since they are combined in ubuntu_trusty_main_i386_Packages; however, it is necessary to include all of their security repos, right? IIRC the main security repo is automatically added in a fresh installation and so should be then all other security repos.

If so, do you see a chance to somehow create the same mechanism (DEBINX provided by Core) for the security repos in parallel? I think it would be very desirable to create a DEBINX file for all the security repos together provided by Core.

You say you cannot combine duplicate packages into on DEBINX-file which seems very clear. What about providing two distinct DEBINX-files, one with the "original" sources as given and the other one with the security packages only. There would be no over-lapping and it would simply be one more file to handle. I do not know if the mechanisms of sce-import support pulling in a second DEBINX-file from the Core-repo, though.

[Jason W]

Yeah, I will aim at creating two 'invisible to the user' debinx's, one main and one security.  That makes sense since security is not extra and is in preference to the main by default.  I will get that going.

[Jason W]

And there are security repos for main, universe, multiverse, restricted for the Ubuntus.  So that would mean 4 files in /opt/debextra.  I can combine those files on our server like the main and make it much more efficient, and make the second non-extra DEBINX.

[LichenSymbiont]

Great work with the wiki sm8ps! I'm sorry for giving you the impression that I'd be more involved when we started. But you've done an excellent job yourself, so I shouldn't be too sorry ^^

I'm more a lazy learner, that learns by doing and working things out myself and in my mind. So I shall continue to work on the installation script, and my GUI environment for dCore (and Linux in general). So learning by doing will be fun and easy, by having plenty of examples and templates to work from available to the users.

But once the script is working well, to install a basic system, with sound and compatible graphics, I will put some more effort into the wiki as well.
But first I want to get to TC's level of ease to install and use. By being able to open a terminal in the WM (probably JWM), for running sce-import (which asks the user for a package, when one isn't provided).
But if I can get my own XCB-based WM off the ground in time, it would be easy to implement a package manager by an edit-box and a regular menu-list for packages found, by having the WM execute sce-import with the text in the edit-box.
If JWM had an edit-box element, and more root-menus (it just has 3), I would have implemented it there already.
Though you could probably implement a simple xdialog in a script, which refreshes a JWM menu with the search-results, as well.

Keep up the good work!

[sm8ps]

Added link to dCore welcome page on main page of Core-wiki. Hope nobody minds!

It would be great if  somebody could put that link into the navigation panel! I shall send this request to user gutmensch via PM.

[sm8ps]

Regarding RAM usage of SquasFS mounts: this means that there is no real point in trying hard to combine extensions by use of dependencies other than saving disk space, right? The sym-linking does not take much time either.

[Jason W]

Correct, using a file list or SCE dependencies saves disk space primarily.

[curaga]

There is some boot time advantage, as each mount takes a certain time.