Table of Contents
dCore sce-import and deb2sce Script Review
These scripts are fairly complicated, forum member LichenSymbiont's guide to some of dCore's most important scripts, sce-import and deb2sce.
The sce-import script is a commandline package manager that calls deb2sce to retrieve .deb files and collect them into an SCE extension. It also calls the update function for the indices of Debian packages (debGetEnv). As you should expect, it must handle the regular Debian and Ubuntu package repository mirrors. Beyound that, it also downloads the dCore specific dependencies, and excluded packages, for the .deb packages (contained in /dCore/$build/import/deb2sce.tar.gz on the FTP). It also contains specific packages compiled for dCore (fltk library, flwm_topside and others).
An SCE extension is a SquashFS file, which can compress data using multiple compression algorithms. Unfortunately it has one problem: it can't overwrite or delete its stored files – only create new copies of files. So if a file with the same name exists in the same directory, it adds the new file with “_#” (_1, _2, _3 …) appended to its file-name. So you can't easily update its stored files, without rewriting the whole thing. But you can add new files to an already created file-system. Detailed information is available in this SquashFS HowTo. This allows for the creation of SquashFS files that stores all your favorite programs, in one file, by just incrementally adding them (this is not a feature of sce-import yet).
These SCE extensions are mounted as loop-devices through loadsce (which just uses “mount -t squashfs -o loop…”), and located in the file-system at /tmp/tcloop/. loadsce also loads all the dependencies of a package.
Helpful Links: The scripts uses grep and awk extensively, so you should read more about using them. It also uses some more complex awk programs, so you should learn a bit about the Awk language. And of course you need to know bash scripting, so here is a guide. And understand some pitfalls in Bash (some applicable to Ash): Bash Pitfalls.
sce-import
Now I will walk you through the sce-import script, so download the latest scripts, here.
And follow along, looking at the actual sce-import script.
- First it sets global variables for the script, and sets up the /tmp directory.
- Then removes temporary files (potentially left from a previous run of the scripts).
- Then it sets the mirrors to the dCore specific packages and the file with extra dependency information for packages.
- Then sce-import sets a bunch of variables from the options used when calling the command. Then from its config file, if it exists (though it doesn't presently check this, just grep's the options). So the config file takes precedence over the command-line options.
- Then decreases OPTIND by one, making the first argument the package name (instead of the one-letter options)
- Then sets the target .sce file to be created (just sets the TARGET variable to the package name used when calling it).
- And enters the /tmp directory.
- Then downloads the special dCore packages (like Xprogs and flwm_topside), and special dependencies for certain packages (which don't show up in a regular Debian system (as they would already be installed)). There are also other things, like dependencies to exclude. You can study the file yourself, by downloading it from here (extract it into a new directory, as the files are in the root of the package).
- Then extracts its content into a bunch of text-files.
- Then checks if the target package is to be excluded (and exits if it's on the excluded list).
- Then it checks if a .lst file (file containing a list of packages to download) is being used, and changes the targetted .sce accordingly.
- Then it checks for more options from the config file, and then checks if you are trying to use a Windows file-system to extract files to (and if so, it informs the user of this, and exits).
- Then it let's you enter a package name, if no target it specified (why is this so far down the script?). And exits the script if you don't specify anything.
- Then it checks if it can find the package in the package indices (both regular repos, and meta-packages and special dCore packages). This is done through the debGetEnv script, which also stores the relevant repo in the DEBINX variable.
- And finally it calls the deb2sce script (through the mksce function) after a bunch of checks, which does the real work of downloading the package(s) (with dependencies and all).
Then after deb2sce has downloaded all of the required packages, it runs the mksquashfs program, which takes all of the downloaded deb files and makes the sce package.
deb2sce also does the -l option operations, of importing packages from a file containing a list of packages.
deb2sce
This script apparently sets up the /tmp directory all over again, and sets some of the same global variables.
First skim over the functions, to understand generally what they do.
- Then we start at #Main, where it first checks the options that deb2sce is called with. And where it exits the script if no target is specified.
- Then it displays the repository (DEBINX) and mirror to the user.
- After it removes the unused debinx files, it checks if the user is using a package-list file for making a collection in an sce file.
- Then checks if the package collection matches already existing meta-packages, and sets the META variable if it is matched. And if it's not, the META variable is set at the top of the if-statement block, so META will always be set when using your own package list. The /tmp/.targetfile is set by sce-import, and is just a copy of your custom package list.
- If it matches a regular Debian package, it sets the mirrors and other variables pertaining to the repo containing it, and displays this information.
- Then it creates the directory for the stored deb files, and sce files. And changes the import directory to the in-RAM one, and enters it, if you have set this option.
- Then creates and enters the temporary directory for extracting your package(s).
- Then it gets the dependencies for your package(s), using debGetDeps – iterating through the contained packages in your package list – if that's what you are using.
- Then it checks if there are blocked/excluded packages, which is set by debGetDeps.
- Then it gets extra dependent packages from /tmp/.importdep, which is set by sce-import.
- Then checks if the target sce already exists (why so far down?).
- Then it checks if a .dep file already exists for you target package, and informs the user of them.
- Then it checks if there is enough space to extract into.
- Then it adds the new dependencies to the temporary dependency file (/tmp/.pkglist).
- Then the interactive import logic.
- Then it gets the package description file for packages, and extracts it into the temporary target extraction directory. This is a big block of code.
- And finally, in this big loop, it downloads the .deb file as well, using the fetchDeb() function. And extracts it into the temporary target dir.
- And finally, after a lot of operations (a bit too complicated to put here now), it uses mksquashfs to compress the temporary target directory into a SquashFS file – the sce package.