Is it time to consider SBo binary packages?
 

Hi all, Ill try not to be long winded.

Please don't rip me a new one, I am well aware of Slackware and SBo policies, I am just thinking out loud here and I almost always try to stay away from "Politics of Slackware or Linux posts" and I will ALWAYS trust the judgement of Pat and the core team.

Like a lot of of people who have used Slackware for years I remember the days of compiling software manually or using Checkinstall, src2pkg, rpm2tgz, or if you wanted to be brave www.linuxpackages.net. There were a lot of different options if you knew where too look, but this also could easily affect the integrity of Slackware's reputation for stability due to lack of know exactly where and how a package was created. Fast forward to today where we have Alien Bob, Robby, Willy, Pounce, slacky.eu, SBo and amazing tools like sbopkg, sbotools, slackpkg+, etc that work with those repositories, we basically now have dependency resolution and automation for installing quality approved packages. Even with that every single time I talk to a Linux user about Slackware, no matter how they word it, it always boils down to lack of binary packages and their apprehension of a source based solution. Is it time to at least consider SBo binary packages to attract more users? With SBo you have the SlackBuild, the person who made it, core team member approval, basically you have peace of mind. I would still compile from source but I would easily trust a SBo binary.

In closing I just want to say that I will always compile my software from source. To me it gives you an extra benefit of knowing your system is working the way it should and being able to tweak things if you need to. I also firmly believe in the old saying "If it ain't broke don't fix it" and binary packages could lead to WAY more problems than solutions and I don't want to see anything compromise Slackware's reputation. My only reason for even thinking about this is I truly think that if Slackware started offering binary SBo packages it would attract a significant amount of new users which would hopefully correlate to more money for Pat which would keep Slackware alive any healthy for years and years to come.

Opinions?

there's the SlackOnly repo

https://packages.slackonly.com/pub/packages/

enjoy

here's my reasoning for using it:

https://slackalaxy.wordpress.com/201...arty-packages/

I don't know. I think if those users are hung up on compiling something from source that already has an automatic and well-tested build script, there are probably a lot of other things in Slackware that they will be hung up on too. I say let them use their Ubuntu if that's the kind of distro they want.

From a practical standpoint, I don't know if the manpower exists to do all that work and quality control. In any case, I don't think it's worth it. I'd rather have our dedicated SBo admins and contributors doing more worthwhile things.

IMHO, a binary package repo should be separate from SBo. Part of the reason is that SBo gives you good flexibility in optional dependencies and build options, both of which a binary package repo would need to handle differently.

I assume those people don't care for Gentoo, either.

That's actually pretty cool. Didn't know that existed. Like I mentioned I will still use SBo, but that seems pretty polished and it works with slackpkg+. And I agree with dugan, when you think about how many SlackBuilds have switches and options it does make sense to keep the repos separate.

People who choose Slackware want to use the distribution; I don't think they need to be coaxed into using Slackware. Having said that I don't see anything wrong with the idea of SBo binary packages. It is an ambitious project; it sounds like a lot of work.

Salix is an excellent option for all those who don't want to build all the extra stuff. Their binary repo is quite impressive, and slapt-get handles dependencies just fine. This being said, all the other control freaks out there like myself will always prefer Slackware.

Yeah, and who is supposed to do all that work? Also consider that this will cost money, not just labor. SlackBuild scripts have negligible filesizes but downloading a Slackware package requires bandwidth. And hundreds of users downloading hundreds of packages require loads of bandidth, a reliable server and a lot of storage.

If you would want to start such a project you would try to minimize the amount of manual intervention or you will go crazy. Some CI tool like Jenkins could be setup to use the SBO git repository as a source and (re)build a package when its SlackBuild entry gets an update in the git repository. That would make it almost fully automatic, plus it will catch any issue the SBo admin team might have missed during their QA testing.

Adequately powered server and unimited bandwidth would have to be provided by real hardware, like a DediBox of 16 GB RAM and 1 TB harddisk, at 16 Euro per month pre-tax: https://www.online.net/en/dedicated-server/dedibox-xc - but those monthly fees would have to be covered.

If you look at slackonly.com, they already provide all these packages. The question is: how do you build a web of trust? I do not know Panagiotis Nikolaou. Would I install his packages? Probably not. Would I install his packages if he was a well-known member of the community with enough credibility? Perhaps yes.

Like most big Slackware contributors, Panagiotis Nikolaou made slackonly repository for his personal needs (and some close friends') about 2 years ago.
He then, generously, opened it for the community.
Me, and a growing number of slackware users, have it configured on our slackpkg+ setup.

How long would it take for him to be credible in the eyes of a core team member such as yourself?
I'm just curious. Like I said, I already use it... but I wonder why it is not more widely used.
Is it just a credibility issue? Does it need more advertising, since some people are surprised that it already exists?

It ain't broke.

Don't fix it.

Cloud hosts also charge for CPU usage.

So, how do you build a web of trust?

That's a technical question. The answer is crytographic signatures.

Indeed.