I'm still seeing this dependency management topic raised as an issue and a limitation that Slacakware suffers from. I find the SlackBuilds idea very good and I cannot think of any better extra packages delivery system that can be as flexible and transparent(traceable) as Slackbuilds is. There are only two minor issues with it ATM, MD5 should be dropped in favor of at least SHA256 or GPG and there is no timestamp on the webpage (last modified) to track the activity (well, you can check it after downloading the files). A system that will test the builds on daily basis and flag them as OK/BROKEN might be very useful, but that will take a lot of computation power and the feedback here on the forum might still remain the optimal alternative. Regarding dependency resolution of the extra packages, without using it myself, it looks like there is a working solution people are happy with:
https://www.linuxquestions.org/quest...ol-4175596457/
As for the "thousand build scripts falls short of the repositories of the current mainstream distros", I'm wondering what are those extra thousand packages that mainstream distros are offering and how important are these after all - worth considering them?
With respect to the package management on multiple instances (cluster/cloud) that are to be done at sysadmin level, usually you only need to change the hostname/networking configuration when deploying and the rest of the system remains the same, thus, you're able to deploy your extra packages that you compiled on all these systems by using an orchestration tool like Puppet or Chef.
Personally, I wouldn't trust any binary package that doesn't have the stamp from Patrick. It's a relation of trust I built and I hope he's knowledgeable enough to keep his build farm secure and assure data integrity, which turns to be more and more difficult these days.

3 members found this post helpful.

This is an excellent point. For all that the lack of dependency management rubs some people the wrong way, its benefits are undeniable. It improves the flexibility, transparency and robustness of the system.

+1 to SHA2. The danger with MD5 (however slight) is that an adversary could target the user with a preimage attack -- inject malware into a source package, find a string which would make the modified package match the unmodified package's MD5 digest, include that string in the source package, and use a MitM attack to substitute packages when the target user downloads it from the Slackware site.

MD5 isn't terribly vulnerable to preimage attacks, but it's more vulnerable to them than one might like -- https://security.stackexchange.com/q...bility-in-2017

As unlikely as such an attack seems, the Snowden Revelations demonstrated that the security community hasn't been paranoid enough, and attacks that seemed incredibly far-fetched have been carried out regularly.

On one hand, this is important to the admins I've talked to. The perceived lack of packages is one of the points that puts them off to considering Slackware. I've been tracking some of the missing packages for my "enterprise slackware" interest.

On the other hand, it's not as bad as it seems. Other distributions practice package inflation, splitting packages into multiple related packages (one for "core", one for headers, one for libraries, one for documentation, etc) where Slackware keeps all of the related software in one package. This means Slackware is "missing" far fewer software projects than it would appear from a quick comparison of package counts, especially once the packages from slackbuilds.org are factored in.

Tangentially, a while ago someone in #perl channel was collecting mappings of CPAN modules to distribution-specific package names, so I gave him the mappings for Slackware. Upon reviewing the mapping, he came back to me and insisted I had made a mistake, since some non-core modules were listed as mapping to Slackware's "perl" base package.

I had to assure him that there was no mistake, and point him to the online repository's source/d/perl/ directory, which shows that these non-core modules are provided by Slackware's "perl" base package. This is unheard of in Debian/RHat distributions.

I'm not sure how to combat the appearance of Slackware "offering less", though.

What I've done at home is to build SlackBuild packages on a "gold copy" system, and then use it as a binary repository for other systems to install from.

This approach should scale well to datacenter-scale deployments -- instead of downloading packages over the internet onto each of 1,000 servers, and each server building it themselves, the packages could be built on one central on-site "boss" server and then installed on the 1,000 other servers from there.

Idlemoor's SlackRepo project provides this capability, but it's not packaged with Slackware nor provided by sbo -- https://github.com/idlemoor/slackrepo

6 members found this post helpful.

Nothing you personally can do about ...

I've been using Slackware before Slackbuilds was available and I did maintain some systems that were not online (fileservers,Samba,DB,etc), got used to download the source packages directly from upstream and bring them with me on diskettes or CDs, later USB drives, compile them, create packages (later on - before I just archived the compilation directory) and update those systems. Always tailoring the packages - that's manually checking the configuration parameters and cutting all the unnecessary features. I'm still used to do that nowadays and I regard it as a learning opportunity, helping me understand the "tools" I'm using, tracking changes and subjectively, providing me some satisfaction getting my hands dirty with building blocks. It's only lately that I'm peeking at the SlackBuilds, usually if I encounter some issues in the compilation process, mainly looking for patches or environmental variables I was missing. But that's me, a "retro hipster"

But now the SlackBuilds system is endorsed officially on the Slackware main page and I believe it's missing a little bit of details, just to give the potential Slackware user a better understanding about the way Slackware handles extra packages, without scaring him off.
http://www.slackware.com/
"Build scripts for all kinds of additional software for Slackware 14.2 can be found on the slackbuilds.org website."
- should maybe be reworded emphasizing on the way these extra packages are offered, pointing out the flexibility, transparency and traceability.
- I'm not a native English speaker, so forgive me for any idiomatic mistakes (feel free to correct me), but I'll put the above line like this:
"A plethora of useful additional software packages for Slackware 14.2 can be found on the slackbuilds.org website. By valuing flexibility, transparency and traceability these additional software packages are provided as an unmodified upstream source package together with an automated and editable/adaptable build script and need to be compiled by you. Empowering the user is what makes us happy."

Then on slackbuilds.org a packages counter might be useful and the following statement should be maybe moved on the top and reformulated a bit, it reads a little fuzzy, use the core values "flexibility, transparency and traceability" instead of "we want". (like I care what you want )
"Our goal is to have the largest collection of SlackBuild scripts available while still ensuring that they are of the highest quality - we test every submission prior to inclusion in the repository. We do not now nor will we ever provide precompiled packages for any of the applications for which we have SlackBuild scripts - instead, we want the system administrator (that's you) to be responsible for building the packages."
There is no clear definition what Salckbuilds is providing, missing a sentence how a Slackbuild is organized, how is to be used (there are threads in this forum started by people who didn't understand how to use it), what it contains of, and the wording is apologetic (don't understand why?) and differentiate SlackBuilds from official packages, like the official packages are not built the same way. Anyways, even officially not assumed/supported, people are still coming here on the forum and getting help. I would just cut that "official"/"unofficial" references out.

The adoption of this and other such automations should maybe make the subject of a poll and have the blessing from "above".

2 members found this post helpful.

Some people here are basically asking for Slackware to be turned into Devuan. Why are you using Slackware instead?

3 members found this post helpful.

Hopefully nobody understood me that I am promoting dependency checking. Only I was commenting that the foundation idea might provide a way for both sides of the debate to be happy. With the foundation idea, Pat's base work would not provide that checking -- other foundation members would.

Even without the foundation idea, Pat could throw gslapt/slapt-get into /extra and if the Salix devs are willing, absorb their dependency checking system into /extra as well.

The lack of a central repo limits my decision making at work. Fundamentally, I am paid to take care of the owners. Should I meet the beer truck head-on, I need to leave behind something that others can manage. Compiling packages is not part of that business focus.

If Pat decides he wants to target business users then I think a large central repo and dependency checking are required. If he decides that is not part of his focus then the discussion is moot.

BTW, when I return home I am surrounded by Slackware. I don't think twice about compiling packages and doing my own dependency checking. Just not going to happen at work.

Interesting point -- although Pat himself opened the doors to suggestions.

Seriously, is there a reason this wouldn't make everybody happy?

1 members found this post helpful.

I am curious. If all slackbuilds.org packages were available as binaries, and all third-party repos were included (AlienBob, Salix, MATE, Cinnamon, etc.), how many packages would then be available with point-and-click? Yes, possible with third-party command line tools too, but I am curious about the slapt-get potential.

This is precisely why I use Slackware and my biggest frustration point with many other distributions I have tried in the past. It is why I have always returned to Slackware. I stopped looking ages ago.

5 members found this post helpful.

slackbuilds.org packages exists as binaries, https://slackonly.com/
also if I do not fully understand in which interval they update
I use if for some packages I do not want to build on my notebook because its a wast of energy and time

slackonly can be added to slackpkg+
(and I would consider slackpkgplus a less third party tool than slapt-get)

I would not recommend to use the Salix repo for Slackware
AlienBob repo should exist binary, and is also available in slackpkg+
not sure about MATE and Cinnamon, hope they also exists

1 members found this post helpful.

In the sense that it is based on slackpkg, now shipped on Slackware, yes. But IMO it's less mature than slapt-get and a lot more difficult to configure (partially because it has more options).

I don't see any issue doing that, but you'd need slapt-get.
See on Darren's mirrors Cinnnamon and Maté, thanks to Willy. Both repos are slackpkg+ ready, by the way. As an aside, this is also true for https://slackonly.com/, that can also be used with slapt-get.

@All: usual caveat: mixing repositories including packages not built with the same options/dependencies/libraries' versions void your guarantee (if any).

PS. almost forgot:It does, e.g. still in Darren's mirrors as sbrepos, thanks Eric.it is, and also in slapt-get. It's included as an option in slapt-getrc for Slint64-14.2.1 (attached).

Attached Files

slapt-getrc.x86_64.txt (1.9 KB, 7 views)

3 members found this post helpful.

Maybe because I was sitting in that lounge long before hipsters come?

It's probably because I use just about dozen of additional packages, all of them installed from source using SBo, plus several tools that are installed using their own installers (like Matlab), but for me it's really hard to follow last part of the discussions. I mean - all these tools: sbopkg, slackpkg+, sqg, and then all of the additional repos mentioned, that's just crazy... How is that it's not obvious, solely from this, that what Pat should do in that regard is: stop being kind of control freak, build a ring of trust, focus on core stuff, let other people handle different subsystems, and put all the damn things on the same repo (or at least in two repos max., if it's really important for you to keep what you produce separated from the rest of mere mortals)? But no, there is still number of people here claiming that current state of affairs is KISS, and the exact beauty of Slackware.

1 members found this post helpful.

I didn't think Slackware was ever interested in making everybody happy.

1 members found this post helpful.

In the past SlackOnly was typically rebuilt during each public update of SBo. This hasn't been the case lately because the package builder, Panagiotis Nikolaou, has been very busy with other things. I wrote the documentation for SlackOnly because Panagiotis needed help due to the fact he is not a native English speaker. I am speaking for him now because he doesn't usually frequent these forums, and I do.

The SlackOnly FAQ and README discuss which package managers are supported by the project- even going as far as providing directions on how to use these package managers with the project. In short, slackpkg + slackpkg+, slpkg, and slapt-get + gslapt are all supported by SlackOnly. The repo is built using idlemoor's slackrepo utility. Automatic dependency checking is supported provided the package manager supports it.

There are a few issues with dependency tracking. For example, ffmpeg lists its dependencies in its README instead of the .info file, so a few deps are missing in some packages that require ffmpeg. This issue is currently being resolved between myself and Panagiotis. We are thinking of a new way to generate the dependency checking files in the repository that is still compatible with the various package managers.

As has been discussed in earlier posts, the problem we've encountered with SlackOnly is a lack of man power. There are thousands of scripts on SBo and only two of us working on the project. It would be different if there was a standardized way to create a package repo for Slackware with tools that were all cohesively designed to build, host, maintain, do quality control, and do testing for each and every package. As it stands almost none of the software built in SlackOnly has any quality control or testing of the binaries after they are built. Any QA and testing is done on the SBo maintainer side or by SBo administrators when commited to git. We at Slackonly just cross our fingers and hope that everything works. In most cases there are no reports from Slackware users when something is broken. The earlier discussed issue with ffmpeg was only found because I maintain some software on SBo that utilizes ffmpeg as a dependency. I installed slapt-get and found that only some of the deps were being pulled down.

A Slackware foundation would be great. It would snow ball the Slackware community into one focused project. Many of the third party repositories and projects surrounding Slackware lack man power. The know how is all there. Obviously, Pat V. is very capable on his own. However, there are some very talented people working to make Slackware better outside of the Slackware development team. The time is ripe for the Slackware core team to be extended and bring in even more talent.

7 members found this post helpful.

IMO, one of the best suggestions that was made, was done by rkfb in this post
https://www.linuxquestions.org/quest...ml#post5890908
(my sincere and deepest respect to rkfb !)
Obvious?
For me one things is obvious: Slackware is still alive and great(yes, I think so), exactly because of Patrick personality, choices his made. You can call him "kind of control freak" (although, as someone already said here, people using Slackware are also control freak - especially compared to people using <name an OS> ).

You can put forward hundreds clever ideas - "Look at them!" "Times change, now one should do it like that" and so on.
But do not underestimate the facts, see the the forest, not just clever shiny trees.
Also, when we make suggestions to someone, we should not assume that this person spent last ten years isolated from the world, and does not know what is going on, that this person suddenly lost his brain or smth like that.
The most useful suggestions are specific suggestions, and not strategic (the latter is Patrick's domain).
So, let's be more specific.