PROCEDURE PROPER
Et voila!
Technical Details of Procedure
And here I say to script gurus far and wide, in the bashful words of francois

, please don't laugh at an initiate's attempt to write a program in Bash, nor frown on the coding style!

And the Newbie who claimed that the command line is arcane will never really know what arcane is until he/she tries to do something meaningful in Bash. In the immortal words of that famous Belgian, quite a challenge for the little grey cells ...
The procedure presented here is essentially the manual procedure, followed for resolving dependencies on pkgs.org, formalised in a programmatic representation. This consists of a suite of bash functions:
- pakorg() The front end function, taking one argument, which could be one of
- package url
- package distros list
- package name
- pakdep() The 'workhorse' recursive function
- Auxiliary functions
Of Circular Definitions/Dependencies, End Points and Slackware
- Circular Definitions/Dependencies were the cause of the biggest headache, and these have definitely been resolved by the Procedure.

- End Points I have called, for want of knowledge of a better name, the dependencies that are so basic they are bound to be in the system but are known under another name. Also included here are basic libraries of the same name as in the Slackware universe. Such a dependency is then considered the end of a dependency branch. Optionally one could include here higher level packages, which one could get away with, without having.
- Slackware can also be considered an end of branch, as there is the possibility of handing over to USM here.
Role of USM
If a dependency includes Slackware from recognized repo, there is the option of running USM. In this case a module should be made, whether it is one or many packages in the final download, and then the module should be activated. This is to ensure the registration in the system of any subsidiary packages and any associated libraries. They will then be detected if further on a dependency requires a relevant library. (Only the top level package will have been recorded by the Procedure.)
brokenman wrote:if you open the /etc/usm/usm.conf file and change:
MODULES=false to MODULES=true
all your downloaded packages will be converted to Porteus modules in text or gui mode.
...
The MODULES= variable is not set by Porteus as a universal environment variable. When USM is run the config file is sourced and variables therein are temporarily used for the current USM session only.
It would be best for our purposes that usm converts all downloaded packages to modules, and it might be advisable to allocate a separate directory for downloads, by changing STORAGE= in usm.conf, so that the normal download directory does not get cluttered up with a lot of test junk.
A proposed user-friendly solution to switch the usm configuration, without constant editing of or copying to /etc/usm/usm.conf.
- Once-off edit with desired option to /etc/usm/usm.conf in a fakeroot directory.
- Create micro module from directory
- Activate/Deactivate Module to achieve switching of options.
Illustration:
Code: Select all
guest@porteus:~$ mkdir usmod
guest@porteus:~$ cp --parents /etc/usm/usm.conf usmod
guest@porteus:~$ vi usmod/etc/usm/usm.conf # MODULES <- true
root@porteus:/home/guest# dir2xzm usmod/ usmod.xzm
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on usmod.xzm, block size 262144.
[===============================================================================|] 1/1 100%
Exportable Squashfs 4.0 filesystem, xz compressed, data block size 262144
compressed data, compressed metadata, compressed fragments, compressed xattrs
duplicates are removed
Filesystem size 2.12 Kbytes (0.00 Mbytes)
root@porteus:/home/guest# grep MODULES /etc/usm/usm.conf
MODULES=false
root@porteus:/home/guest# activate usmod.xzm
Updating shared library links: /sbin/ldconfig
root@porteus:/home/guest# grep MODULES /etc/usm/usm.conf
MODULES=true
root@porteus:/home/guest# deactivate usmod.xzm
Updating shared library links: /sbin/ldconfig
root@porteus:/home/guest# grep MODULES /etc/usm/usm.conf
MODULES=false
The latest version of USM, when it comes through, could be just the ticket for our testing purposes, creating a module followed by its activation, and would save us the extra step of a separate activation.
Setup for Running (Adhering to KISS Principle)
in dedicated directory
pak requires that:
- file awk_distro, if not already there, is copied to the directory
- file awk_lids, the dependency lister, has also to be copied to the directory
- file pakfuncs.sh is also copied to the directory
The
ua="User Agent String " statement appended to pakfuncs.sh thus:
Code: Select all
echo ua='"Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko"' >> pakfuncs.sh
using as example IE user string.
Run Procedure
- In a New Terminal Tab for Each Run
- As root or using sudo. Otherwise USM is excluded.
- Ensure USM switched to Creating Modules
- Change to directory pak
- Source the Bash Function Suite thus: . pakfuncs.sh
- Invocation thru pakorg <argument>, where <argument> is one of:
- Particular package file url
http://pkgs.org/<repo>/../<package file>.html (file holds the requirements/dependencies of package)
e.g. pakorg http://pkgs.org/archlinux/archlinux-cor ... ar.xz.html - Package distros list http://pkgs.org/download/<package name>
e.g. pakorg http://pkgs.org/download/nemo - Package Name
e.g. pakorg nautilus
- Default Option. Normally taken by just hitting Enter.
- USM. Accept USM If USM has been successful. Before accepting the USM outcome, do ensure that the module so created is activated, before hitting Enter. Activate from:
- Root Terminal: # activate /<Path to allocated download directory>/<module>.xzm
- File Manager
- Test Version. Hence chock-a-block full of explanatory output of a diagnostic nature. This can be progressively phased out.
- Bash going haywire
- Return to command line prompt with Ctl-C
- Save output of terminal to file if so desired
- Close current terminal tab
- Open new terminal tab
- Source pakfuncs.sh anew
- Restart
- A <package>.pak file, for testing purposes, will be written out at the end of a successful run. This needs to be given another name so as not to be overwritten in a subsequent run, should it be worth keeping.
- Logging. Not running in subshell, therefore using terminal menu to save output to a file. Not so au fait on this end of things regarding increasing the size of the Konsole tab output buffer. (File buffer output extends to Just over a thousand of pakorg output lines on Konsole. Looks like a circular buffer of 32 KiB)
- Dry Run
- ON This is the default, and binaries are not downloaded, but just recorded in the binaries download list in file 'Binaries.lst'. Corresponding URLs to be found in 'Binaries.url'.
- OFF Binaries are downloaded on the fly into subdirectory dwn when dry run non-zero switch value is zeroised thus: dry=0. Even after a dry run there is the possibility of getting the binaries using Binaries.url thus:
Code: Select all
cat /<Path to>/Binaries.url | wget -nv -i-[ -P <Downloads Directory>]
In order to facilitate testing, at the end of a successful run a small file with extension '.pak' is created to hold the relevant data of the run. Using the
colord example the file is 'colord.pak'. i.e.
<package name>.pak. This is so that later when finding dependencies for
nemo which has
colord as a dependency, all the
colord dependencies will have been registered, just in case
nemo requires one of them. When saving, the file should be saved as
<package name>_*.pak, e.g. openshot_ 2304-1.pak to allow being picked up by the Procedure on the fly, if it still resides in the directory.
IMPORTANT*IMPORTANT*IMPORTANT
Prior to using the Procedure in anger, please try to get a feel for it, through
Familiarization Runs
Allowing of Procedure Appreciation and Adaptation to the Pace of the Script. Although having written it, the script's behaviour in real time was quite different from that envisaged.
If a slight delay is experienced, it is wget in Internet.
- The Low Road
In a a new tab pakorg colord, always hitting Enter for the Arch package file default, is fairly straight forward, and takes around ten minutes (if you know what you are doing), excluding USM time and Activation time. This should generate around 830 lines of output, should not overflow the terminal buffer (Konsole at least), and should result in just the one log file without loss of earlier output. The binaries download list at run end will look something like this:Code: Select all
cat Binaries.lst
colord-1.2.9-2-i686.pkg.tar.xz
libgusb-0.2.4-1-i686.pkg.tar.xz
systemd-219-4-i686.pkg.tar.xz
hwids-20150129-1-any.pkg.tar.xz
libseccomp-2.2.0-1-i686.pkg.tar.xz
libsystemd-219-4-i686.pkg.tar.xz
lz4-128-1-i686.pkg.tar.xz
pam-1.1.8-5-i686.pkg.tar.xz
cracklib-2.9.1-1-i686.pkg.tar.xz
libtirpc-0.2.5-1-i686.pkg.tar.xz
pambase-20130928-1-any.pkg.tar.xz
- The High Road
In a new tab pakorg colord, but this time press 1 for Select by Type, and then 2 for RPM. At the prompt hit Enter to suspend the listing, then select the 9th Package. Thereafter hit Enter, taking Default unless contraindicated. In that case Select by Package and take the first acceptable Package. May have to scroll back to get its number. Thereafter just hit Enter for default option.
In the case of libraries there will be an annoying second confirmation requested for the time being. Also formatting has gone slightly awry after having to take into account the Tags on Versions. There is no need to lose touch with the progress of the run, as one can always scroll back to the last Interaction. Logging the run will mean saving output of terminal at regular intervals. Have managed with 3 files. There is no reason why this can't run as a background task, interleaved with other real-life tasks. Took some 40 minutes wall clock time, as a background real-life task during which time I was getting my supper and having it.
At the end you will end up with a binaries download list somewhat like this, Code: Select all
colord-1.2.4-4-omv2015.0.i586.rpm
colord-libs-1.1.8-1.fc20.i686.rpm
libgusb-0.1.6-2.fc20.i686.rpm
systemd-libs-208-31.fc20.i686.rpm
pam-1.1.8-2.fc20.i686.rpm
audit-libs-2.4.1-1.fc20.i686.rpm
cracklib-dicts-2.9.0-5.fc20.i686.rpm
cracklib-2.9.0-5.fc20.i686.rpm
libdb-5.3.28-1.fc20.i686.rpm
libpwquality-1.2.3-1-i686.pkg.tar.xz
libselinux-2.2.1-6.fc20.i686.rpm
libsepol-2.1.9-2.fc20.i686.rpm
rpm-helper-0.24.12-3-omv2013.0.noarch.rpm
chkconfig-1.3.63-1.fc20.i686.rpm
setup-2.8.71-3.fc20.noarch.rpm
shadow-utils-4.1.5.1-8.fc20.i686.rpm
libsemanage-2.1.10-14.fc20.i686.rpm
ustr-1.0.4-15.fc20.i686.rpm
systemd-units-208-8-omv2013.0.i586.rpm
and you will have been successful if you had cracklib-2.9.0-5.fc20.i686.rpm among the binaries. 
Am well travelled on both roads

So should easily iron out any difficulties encountered, or deal with situations not understood.
Rationale of Prioritization- Priority Of Distro Types
- Arch with it's exhaustive description, ease of modularization for testing, and ease of later conversion to package, I have given first place.
- The broad spectrum of RPMs. And here have given priority to the individual distros. in their display, dependent on how useful they have been to me.
- DEBs have gotten the lowest priority, as there is also the package manager SPMDebian available to deal with them
- Priority of package Versions. Again have found that the lowest versions seemed to have the best compatibility with Slackware 14.1, So, the lowest versions have the highest priority, as far as their display is concerned.
- Versioned Libraries are beyond the pale

Non-architecture-dependent Files following in continuation Post
- awk_lids Listing the Dependencies/Requirements of a Package
- pakfuncs.sh The Suite of Bash Functions
EPILOG
Replacement/Upgrade of System/Slackware Packages
This may be needed by certain applications, even though the crucial dependencies have been resolved. A case in point being those based on GTK+, a particular example of which is illustrated by Arch gimp package: gimp-2.8.14-1-i686.pkg.tar.xz.
Code: Select all
guest@porteus:~$ ldd /usr/bin/gimp|grep not
guest@porteus:~$ gimp
gimp: symbol lookup error: gimp: undefined symbol: g_option_context_parse_strv
Upon consulting the Internet,
Code: Select all
guest@porteus:~$ gimp -v
GNU Image Manipulation Program version 2.8.14
git-describe: GIMP_2_8_12-2-ge62e6fe
using GEGL version 0.2.0 (compiled against version 0.2.0)
using GLib version 2.36.4 (compiled against version 2.40.0)
using GdkPixbuf version 2.28.2 (compiled against version 2.30.8)
using GTK+ version 2.24.20 (compiled against version 2.24.24)
using Pango version 1.34.1 (compiled against version 1.36.6)
using Fontconfig version 2.10.93 (compiled against version 2.11.1)
using Cairo version 1.12.16 (compiled against versionn 1.12.16)
it can be seen from the above that some of the program versions being used, lag behind the compilation time versions. So, short of doing a complete compilation with the latest source versions of above-mentioned programs, there is the possibility of finding the offending program and replacing it with the latest available version.
Since Pango was singled out as a culprit with the same undefined symbol in an Internet instance, there was no reason not to try a latest available version replacement of Pango:
Code: Select all
guest@porteus:~$ gimp -v
GNU Image Manipulation Program version 2.8.14
git-describe: GIMP_2_8_12-2-ge62e6fe
using GEGL version 0.2.0 (compiled against version 0.2.0)
using GLib version 2.36.4 (compiled against version 2.40.0)
using GdkPixbuf version 2.28.2 (compiled against version 2.30.8)
using GTK+ version 2.24.20 (compiled against version 2.24.24)
using Pango version 1.36.8 (compiled against version 1.36.6)
using Fontconfig version 2.10.93 (compiled against version 2.11.1)
using Cairo version 1.12.16 (compiled against version 1.12.16)
guest@porteus:~$ gimp
gimp: symbol lookup error: gimp: undefined symbol: g_option_context_parse_strv
Anyway, happening upon the GTK+ website was able to find the context of the offending undefined symbol, ascertaining it was introduced at version 2.40, and then extrapolate to the gimp compilation time GLib version 2.40.0. Corresponding package for GLib eventually tracked down as glib2. GLib updated to latest Arch version:
Code: Select all
porteus:~$ gimp -v
GNU Image Manipulation Program version 2.8.14
git-describe: GIMP_2_8_12-2-ge62e6fe
using GEGL version 0.2.0 (compiled against version 0.2.0)
using GLib version 2.44.0 (compiled against version 2.40.0)
using GdkPixbuf version 2.28.2 (compiled against version 2.30.8)
using GTK+ version 2.24.20 (compiled against version 2.24.24)
using Pango version 1.36.8 (compiled against version 1.36.6)
using Fontconfig version 2.10.93 (compiled against version 2.11.1)
using Cairo version 1.12.16 (compiled against version 1.12.16)
guest@porteus:~$ gimp
/usr/lib/gimp/2.0/plug-ins/web-page: error while loading shared libraries: libwebkitgtk-1.0.so.0: cannot open shared object file: No such file or directory
(gimp:28959): LibGimpBase-WARNING **: gimp: gimp_wire_read(): error
Traceback (most recent call last):
File "/usr/lib/gimp/2.0/plug-ins/text-brush.py", line 20, in <module>
from gimpfu import *
File "/usr/lib/gimp/2.0/python/gimpfu.py", line 76, in <module>
import gimp
ImportError: /usr/lib/gimp/2.0/python/gimp.so: undefined symbol: PyUnicodeUCS4_SetDefaultEncoding
Application now running. There is however an unresolved dependency and an error warning, which one could try ignoring for starters.
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB