site  contact  subhomenews

Automatic generation of dependencies for Slackware packages

June 25, 2019 — BarryK

I posted about progress with generating dependencies for the Slackware package database in Woof (my fork of Woof, sometimes named woofQ or woofE):

...that script created file 'DEPENDENCIES'.

I have now modified the '0setup' script in Woof, so that it maps the dependencies in file 'DEPENDENCIES' to 'DEPENDENCIES-slackware', which is names of all Slackware packages and their dependencies.

I have done this for the 14.2 version of Slackware. '0setup' downloads the 'PACKAGES.TXT' files from the Slackware package repositories, and converts to "Puppy package database format", which is these files:


'0setup' uses the information in 'DEPENDENCIES-slackware' to insert the dependencies into these files (field-9 of each line).

Yes, I know that the Salix distro does have deps for each package, and '0setup' does read that. However, going forward, I don't want to have to be dependent on Salix. I may do a build that accesses only the official Slackware repositories, which do not have deps information.

Mapping the Ubuntu package names to Slackware names is in most cases no problem, as it is the same name, sometimes with some capitalization in the Slackware name -- for example Ubuntu has 'libx11', Slackware has 'libX11'.

Some name differences are more tricky, and I hope that I have caught most of them. For example, Ubuntu has 'libfile-basedir-perl' and Slackware has 'perl-File-BaseDir'.


Any distribution that is built from the slackware*-current packages, is, by definition, a rolling release. This includes some puppies that you can find in the Puppy Forum.

I was considering trying to provide package management for this scenario. It is easy to include version of each dependency in the above 'Packages-*' files, for example "+libX11&eq3.6.7", however, actually using this information is tricky.

I don't have sufficient motivation to follow this through. Instead, my intention is to build Easy from the Slackware version 15.0 binary packages, when it is released. In that scenario, it will not be required to have versions of dependencies in the database.

Alternatively, I could take a snapshot of all the slackware-current repos, and host them somewhere, give them some arbitrary version number such as 14.90. However, that is rather a lot to host. 


The latest Woof tarball is here (note, there is no online version management hosting for my Woof): 

Tags: easy

Generating DEPENDENCIES took 10 days

June 24, 2019 — BarryK

I posted about the official Slackware packages not having dependency information:

I figured out a way to automatically generate dependencies. Firstly, use the Ubuntu package databases to extract a list of all packages and their dependencies.

This list will be the actual package names, not the names of DEB files -- for example, the 'alsa-driver' package is split up into DEB files named 'alsa-base' and 'linux-sound-base'. Debian and Ubuntu really "go to town" with this pulling apart of the original packages, sometimes into several smaller DEBs.

The good thing about Debian and Ubuntu packages is that they usually turn on every possible option when configuring and compiling a package source, so the dependencies list will have every possible dep that the package is capable of having.

I wrote a script in Woof, support/generate-deps-list, that will create a file named 'DEPENDENCIES'. It has lines like this:

aalib: gcc-8 glibc gpm libbsd libx11 libxau libxcb libxdmcp ncurses slang2

The idea is that matches can be found in the Slackware packages, and dependencies list can be derived for the Slackware package database.

Anyway, the script 'generate-deps-list'. I knew that it was not written in the most efficient way. To chase all deps, it employs recursive function call, and I knew that was going to be slow. When it started to run, I thought, no rush, will just wait until it completes...

This afternoon, 10 days later, it has completed. Probably a good thing that I am running this PC off a UPS!

I did a bit of work on the script, so if ever have to re-run it, it will be faster.

The next step is for the '0setup' script in Woof to read 'DEPENDENCIES' and generate 'DEPENDENCIES-slackware' and then insert the deps into the Slackware package databases. 

Tags: easy

cdrtools package for EasyOS

June 09, 2019 — BarryK

I posted yesterday about a negative experience using pBurn:

EasyOS has an old version of pBurn, the last version that supports cdrkit.

Need to evaluate the latest pBurn, first step is to change from cdrkit to cdrtools.

Download link and compile instructions for cdrtools can be found here:

I have compiled it and created a PET:

Next step, download the latest pBurn... 

pBurn success

I am happy to report that cdrtools and latest pBurn works. I burnt the Absolute Linux ISO to a DVD-RW, and it verified OK.

There was already pBurn 4.3.16 in the 'noarch' repository on, however, I have modified it a little bit:

The little change that I made is move '/root/.config/rox.sourceforge/net/OpenWith/.application_x-cd-image' to '/etc/xdg/', as this is where EasyOS keeps all the mime-sensitive symlinks for ROX.

I also renamed 'Burn with pBurn' to 'Burn-with-pBurn', as Woof has a problem with the spaces -- perhaps that is fixed in woof-CE? 

Current users of EasyOS can install these PETs. I took the precaution of first "uninstalling" the original pBurn, via the menu: "Setup -> Remove builtin packages", before installing the new pBurn. 

Tags: easy

Very negative experience with pBurn

June 08, 2019 — BarryK

This morning I had a very negative experience with pBurn, the CD/DVD burner app in EasyOS. pBurn is version 3.7.18, the last version that supports cdrkit. There are later versions, that required cdrtools.

I downloaded Absolute Linux, a 2GB ISO file. Then attempted to use pBurn to write to a DVD-RW.

pBurn uses /root/my-documents/tmp as temporary storage, and I have 5.9GB free space in it. Note, /tmp has a tmpfs mounted on it, with 7GB free.

Proceeded to write the ISO to the DVD, it got to 99.9% completed, then came up with an error message "ran out of temporary storage". What! How can that be?

The surprises did not stop there, as I then discovered that the 2GB ISO file that I had downloaded, had been deleted. Yep, deleted, erased, vamoosed.

First question, why is temporary storage required? It isn't, an ISO file can be written to CD/DVD directly, there is no need for any temporary storage.

Second question, how can a 2GB ISO file use up 5.9GB of storage?

Third question, how is it possible to justify deletion of the original file? Without asking!

I downloaded the ISO again, and used the ancient 'burniso2cd', which still works great.

Maybe later version, that require cdrtools, will work better?

That 3.7.18 version is old, a lot of "water under the bridge" since then. pBurn is now at version 4.3.16:, I should install cdrtools and try the latest. 

EDIT 2019-06-09:
Success! I compiled cdrtools and installed in EasyOS, and pBurn 4.3.16, and now have succeeded with writing an ISO file to DVD-RW. Blog report here: 

Tags: easy

Slackware package dependencies

June 08, 2019 — BarryK

Considering using Slackware binary packages for EasyOS, have run into a roadblock.

The Slackware package repositories have a file 'PACKAGES.TXT' that contains information about each package. For example:

PACKAGE NAME:  LibRaw-0.18.12-x86_64-1.txz
PACKAGE LOCATION: ./slackware64/l
PACKAGE SIZE (compressed): 360 K
PACKAGE SIZE (uncompressed): 2300 K
LibRaw: LibRaw (library for decoding raw digital photos)
LibRaw: LibRaw is a library for reading RAW files obtained from digital
LibRaw: cameras (CRW/CR2, NEF, RAF, DNG, and others). It is based on the
LibRaw: source code of the dcraw utility.
LibRaw: Homepage:

Notice that it does not contain dependency information. It really really really should, but it doesn't. However, the Salix distribution, which is based on Slackware, does have dependency information, for example:

PACKAGE NAME:  LibRaw-0.17.2-x86_64-1.txz
PACKAGE LOCATION: ./slackware64/l
PACKAGE SIZE (compressed): 328 K
PACKAGE SIZE (uncompressed): 2130 K
PACKAGE REQUIRED: gcc,gcc-g++,jasper,lcms2,libjpeg-turbo
LibRaw: LibRaw (library for decoding raw digital photos)
LibRaw: LibRaw is a library for reading RAW files obtained from digital
LibRaw: cameras (CRW/CR2, NEF, RAF, DNG, and others). It is based on the
LibRaw: source code of the dcraw utility.
LibRaw: Homepage:

So, how did Salix obtain that? Manually?

What we did back when building puppies from Slackware, such as Michael Amadio's Slacko, was use the 'PACKAGES.TXT' from the Salix repository. Fine, except that the Salix project is dormant. They haven't had a new release since 2016, built from Slackware 14.2. There is no Salix 'PACKAGES.TXT' for slackware60current.

I did a bit of digging, and it seems that Salix may have used "slapt-get" to add the dependency information to 'PACKAGES.TXT', as the Wikipedia explains:

slapt-get does not provide dependency resolution for packages included within the Slackware distribution. It does, however, provide a framework for dependency resolution in Slackware compatible packages similar in fashion to the hand-tuned method APT utilizes.[5] Several package sources and Slackware based distributions take advantage of this functionality. Hard, soft, and conditional dependencies along with package conflicts and complementary package suggestions can be expressed using the slapt-get framework.

Adding dependency information requires no modification to the packages themselves. Rather, the package listing file, PACKAGES.TXT, is used to specify these relationships. This file is provided by Patrick Volkerding and is similar to the Packages.gz file in use by Debian. Several scripts are available to generate the PACKAGES.TXT file from a group of packages. The file format used by Patrick Volkerding is extended by adding a few extra lines per package. slapt-get then parses this file during source downloads. Typically, third party packages store the dependency information within the package itself for later extraction into the PACKAGES.TXT. The inclusion of this information within the Slackware package format does not inhibit the ability for Slackware pkgtools to install these packages. This information is silently ignored and discarded after the package is installed.

So, I either need to find an up-to-date 'PACKAGES.TXT' for slackware64-current (15.0 precursor), or use slapt-get to create it. 

EDIT 2019-06-08:
I should mention, I have read a couple of posts from Slackware developers, supporting the lack of dependency information in the PACKAGES.TXT file, or inside packages. The arguments seem to me to be shallow. There was one post criticizing third-party package managers that have introduced dependencies, such as slapt-get, but again, the arguments are not unbiased.

However, there was one valid criticism of third-party package managers that have package dependencies, that it does not work properly in the slackware*-current package repository. This is because the dependencies do not specify versions.

We used the PACKAGES.TXT from Salix, for Slackware 14.2, and un-versioned dependencies will work fine for a particular release. It means that I should wait until 15.0 is released, or at least until the package versions are frozen in slackware64-current. 

Tags: easy

EasyOS build from Slackware packages

June 07, 2019 — BarryK

EasyOS verions 0.8.x to present (1.0.14), has been built in Woof from binary packages that I compiled entirely from source, using my port of OpenEmbedded/Yocto.

The last update of my OE port, that I codenamed "thud", has issues. It was an lot of work, and trying to fix packages that don't work right, is a never-ending task. The thing is, the major distros have many people working on compiling packages and getting them to work right in the host OS environment. I have to save myself a lot of frustration and leverage on that.

Then there is the problem of getting some packages to compile. That can be very frustrating also. With a major distro, those hurdles are jumped, with the maintainers having created patches and whatever else the package needs to compile and work properly.

Woof, from its inception, was designed to build Puppy Linux from the binary packages of any other distro. That continues with woof-CE, used to build the current releases of Puppy, using, for example, Debian and Ubuntu binary DEB packages.

My fork of Woof builds Quirky and EasyOS. I called it woofQ, but then Quirky got retired, so now just call it Woof, though I suppose it could be named woofE.

I have a philosophical objection to building EasyOS from Debian or Ubuntu DEBs. Various reasons. I don't like the way that they mess around with the organization of packages, and breaking them up into multiple small DEBs. Especially, I don't like the dependence on systemd.

Slackware leaves the packages complete, and pristine, as the original authors designed them. Slackware does not use systemd. Slackware is conservative in every respect, and is one of the few remaining Linux distros that remain true to its Unix roots, in terms of simplicity, file hierarchy and configuration.

I was going to wait until version 15.0 is released, but that is a never-ending wait. The current version, 14.2, was released in 2016, and there was some discussion about releasing 15.0 in 2018, but it didn't happen.

So, I will draw the binary packages from "slackware-current", and maybe just assign it as version 14.99.

Importantly, I need to be able to create aarch64 builds of Easy. The official Slackware repository only supports 32-bit ARM, however, there is an unofficial arm64 port:

Slarm64 packages are here:

There are some other aarch64 packages here:

Great, I appreciate the work that these guys are doing, adding aarch64 support to Slackware.  

Tags: easy

Legal declarations for EasyOS

April 14, 2019 — BarryK

Puppy Forum member 'scsijon' informed me of a project named "Easy Linux" registered on It had been registered many years ago, then nothing done, so a non-starter dead project. I contacted sourceforge and they kindly removed it.

However, it got me thinking, EasyOS does need a legal statement page up-front. There is one in the welcome-page at first bootup of Easy, and scattered around in various web pages.

I have put together what I hope covers my arse ("ass" if you are American) in all situations:

...maybe I should add something about this being a totally non-commercial project? 

Tags: easy