Unique strengths of different repositories

rng · 11-18-2015, 06:56 PM

There are many Slackware repositories listed here:

Code:

    SBo Arch: {x86, x86_64} Versions: {13.1, 13.37, 14.0, 14.1}
    Slack Arch: {x86, x86_64} Versions: {3.3, 8.1, 9.0, 9.1, 10.0, 10.1, 10.2, 11.0, 12.0, 12.2, 13.0, 13.37, 14.0, 14.1, current}
    Alien's Arch: {x86, x86_64} Versions: {13.0, 13.1, 13.37, 14.0, 14.1, current}
    Slacky Arch: {x86, x86_64} Versions: {11.0, 12.0, 12.1, 12.2, 13.0, 13.1, 13.37, 14.0, 14.1}
    Robby's Arch: {x86, x86_64} Versions: {11.0, 12.0, 12.1, 12.2, 13.0, 13.1, 13.37, 14.0, 14.1}
    Studioware Arch: {x86, x86_64} Versions: {13.37, 14.0, 14.1}
    Slackers Arch: {x86_64} Versions: {current}
    Slackonly Arch: {x86, x86_64} Versions: {14.1}
    Alien's ktown Arch: {x86, x86_64} Versions: {13.37, 14.0, 14.1, current}
    Alien's multi Arch: {x86_64} Versions: {13.0, 13.1, 13.37, 14.0, 14.1, current}
    Slacke E17 and E18 Arch: {x86, x86_64, arm} Versions: {14.1}
    SalixOS Arch: {x86, x86_64} Versions: {13.0, 13.1, 13.37, 14.0, 14.1}
    Slackel Arch: {x86, x86_64} Versions: {current}
    Restricted Arch: {x86, x86_64} Versions: {11.0, 12.0, 12.1, 12.2, 13.0, 13.1, 13.37, 14.0, 14,1, current}
    MATE Desktop Environment Arch: {x86, x86_64} Versions: {14.0, 14,1}

Are there any unique strengths of any of these. Of course, the official repository would be the most reliable.

Didier Spaier · 11-19-2015, 12:14 PM

Each of these repositories has its own aims, targets, instructions for use, authors, ways of insuring quality and safety, etc. of which you should inform yourself before using them. Which of these characteristics constitute a strength is a matter of use case and opinion.

Just be aware that blindly mixing packages from different repositories could have unexpected consequences.

dugan · 11-19-2015, 01:18 PM

They're all "reliable".

There are basically two things you should be considering when looking at each repo: which programs are in that repo, and are they source or prebuilt?

For me, I haven't used slpkg, but I do use slackpkgplus. And for that I use the official Slackware repositories, Alien Bob's multilib repository (because I use multilib), and Alien Bob's regular packages repository. If I used MateSlackBuilds, then I would add the MateSlackBuilds repository. For SlackBuilds.org, I use programs designed for it: sbopkg and sbotools.

mralk3 · 11-20-2015, 01:43 AM

The main thing to do is go to the links listed on the slpkg repositories section and browse the directories on each server you are interested. For example:

Code:

Slackonly Arch: {x86, x86_64} Versions: {14.1}

http://packages.slackonly.com/pub/packages/14.1-x86_64/

From what I understand Slackonly contains all the binary packages that SBo distributes as SlackBuilds. This means you do not have to compile SBo packages from source. How often is it updated? Not sure, never used it. I like to build from source whenever possible, so I use SBo instead of Slackonly.

I wouldn't start randomly mixing packages though from all of those repositories. You will end up with serious problems when it is time to upgrade packages among the long list of software in each repository. I wouldn't go as far as to say you will break your system. It will just be a mess to figure out what needs to be upgraded and what needs to be left frozen.

I also do not use slpkg as my main package manager. I mainly use it for SBo on my Linux containers since sqg takes so long on low resource environments. It has odd behavior when compared to how slackpkg functions with multilib. slackpkg makes multilib very easy to handle. I am often am reporting bugs to the developer nearly every time I use slpkg. slpkg is great software, but it is not production ready. slpkg is also not for beginner Slackers for that reason, sorry dslackw.

bassmadrigal · 11-20-2015, 06:31 AM

Quote:

Originally Posted by mralk3

From what I understand Slackonly contains all the binary packages that SBo distributes as SlackBuilds. This means you do not have to compile SBo packages from source.

To add to this, Slackonly, as SBo, expect a full Slackware installation and provide no dependency information on packages that are included with Slackware. Since you're running Salix, many programs may not open. Compiling from SBo will at least get you compiling errors if you're missing a required dependency, where with slackonly, you'll only find out if you open the program in the console and hope that it outputs something that helps you track down the dependency.

travis82 · 11-20-2015, 09:16 AM

Slackonly has many problems regarding dependencies. Despite SBo, It doesn't provide enough information about dependencies of several packages in PACKAGES.TXT file. Hence, whatever package manager which is used can not resolve dependencies as they just look at REQUIRED lines of that file.