Thursday, 9 October 2014

We have been mirroring the slackbuilds.org
(SBo) repository and at the same
time applying slight changes to it for some time now. These changes are
essential to Salix, for a few reasons.

First of all, the SBo maintainers have decided that they
will only list SlackBuild dependencies only if these are not part of a
Slackware full installation. While this may be a decision that is fine
for Slackware itself, since they don't offer any kind of support for
users doing anything other than a full Slackware installation, it's
generally not good for Salix, since a Salix installation of any edition,
is slimmer than a full Slackware installation, by far. For example, in
Slackware it is expected that everyone has the Qt libraries installed,
but this is definitely not true for Salix (except from our KDE edition
of course). So, a lot of the SlackBuilds at SBo end up
having missing dependencies when it comes to a Salix installation.

Then, there is a problem with package/SlackBuild naming. We have a lot
of packages in the Salix package repositories that are also present in
the SBo repository. While we try to keep the package naming consistent
with the one they're using in SBo, that is not always possible. For
example, at this moment, there is a package named "python-configobj" in
our package repositories and another one named "configobj" in SBo, which
are actually the exact same piece of software. Even if we made every
effort and named everything at the time of release according to the SBo
names, SBo is constantly changing and SlackBuilds may be renamed.

Another problem (for lack of a better word) is that SlackBuild
maintainers choose to update their SlackBuilds as soon as a new version
of the software they are packaging is out. While this might not be bad
in itself, it kind of conflicts with the way things work for the binary
package repositories in Slackware and also in Salix, which generally
follow the idea that upgrades should only be done for security reasons.
And since there is a very wide overlap between packages offered in the
Salix binary package repositories and the SlackBuilds provided by SBo,
there are often newer versions available in SBo than in the Salix binary
package repositories. This might confuse users, because by opening
Gslapt, they find one version and by opening Sourcery, they find
another, often newer, version. What's more, if they were to "upgrade" to
the version available in SBo, they would find that Gslapt/slapt-get
would want to "downgrade" that package to the version available in the
Salix binary repositories and the only way to stop that would be to put
the package in the EXCLUDE list in their slapt-getrc file.

So, in Salix, we have to deal with these problems. Here's what we do...

Our own copy of the SBo repository, the one that is
available by default to Salix users through our package management tools
is synced with the main SBo repository every few hours.

For the first problem mentioned above, we have a mechanism for adding "missing" dependencies
in our copy of the SBo repository. For example, the ardour SlackBuild
requires cmake to build. Now, cmake is always thought to be
present in a Slackware installation, otherwise it is not a full
Slackware installation and it is not supported in any way. In Salix
though, cmake is definitely not part of a standard installation and
so we add it as an extra dependency for ardour.

For the second problem, we have created a list of packages/SlackBuilds
that are named in a different way between repositories. Every SlackBuild
that is also present as a binary package in the Salix repositories with
a different name, is removed from our own copy of the SBo repository and
every reference to it in dependencies is replaced with the name that the
package has in our own binary package repository. This way, the package
in the Salix binary package repositories is always used, even if it is
originally named otherwise in the original SBo repository.

Finally, all software that is present in both the Salix binary package
repositories and SBo, is removed from our own copy of the SBo
repository, so there is no way users will be confused and go back and
forth between versions. Actually, the SlackBuilds themselves are not
removed from the repositories, rather the reference for them in the
SLACKBUILDS.TXT file is removed, so it isn't used by our SlackBuild
management tools, slapt-src, Sourcery or spi.

With SBo being a moving target though, this process will always be
ongoing and will never be 100% complete. If you find a SlackBuild that
is missing some dependency, please report it, either in our
mailing list or in our
forums. Similarly, if you find the same
SlackBuild present in both the Salix binary package repositories (hence
available in Gslapt) and our own copy of SBo repositories (hence available in Sourcery), please
report that too. Of course feel free to report any other problem you
might find with our repositories.