Sheesh !

Please disregard the request for alternate 'no-samba' packages.

Forget I ever mentioned such a ridiculous thing. ;-)

Nothing wrong with reducing a few dependencies.
But it's simply less work for you to rewrite those -nosamba packages once, than for Pat to build and test them 4 times, for each update of x86 and x86_64.
Bonus advice: always grab sources instead of patches/packages, rewrite your SlackBuilds, tag them accordingly, and script the procedure so you only have to hit one command when there's an update.
According to the license, whatever you write in SlackBuilds you can share or not share, it makes no difference. I made my own updater in bash, called it mybuild.sh and guess what, nobody cares.
Seen at least 5 other users doing the same thing. You might have to fix your own bugs, so be prepared.

Well aware of that, thank you. More worried about the fact 3 different .run installers exist for each version officially, and possibility of another 6 installers for each version unofficially.

Hey folks, Good to see my thread here is alive and kickin' on LQ ;-)

Does anyone know why we have yet to see the official multilib versions of the latest glibc (2.37) version? Generally Eric packages (and posts) these multilib versions a day or two after Pat posts the 64-bit versions. I managed to build the 2.37 version by modifying Eric's glibc-multilib.SlackBuild in https://slackware.nl/people/alien/mu...current/glibc/

I simply merged the files there with the 64-bit glibc source tree. I then modified only the version and build# in Eric's SlackBuild and ran it. However these are not the officially released versions.

In any event my apologies that this is a little OT. What I am really requesting is that Pat gives us an install option for multilib. After all can we realistically expect Eric to maintain multilib forever? I have been running/installing it in almost all my Slackware systems dating back now for 20+ years. Yes you read that right. Eric's first release of multilib I believe was with Slackware 13 - back in August of 2009.

3 members found this post helpful.

Best bet is to contact him on his blog. It's not out of the ordinary to have a couple days between official and multilib updates.

The full announcement can be found at, https://lists.x.org/archives/xorg-an...ry/003321.html

2 members found this post helpful.

I would like to have a set of smaller firmware kernel packages instead of a big ( huge ?) one.
Would it be possibile or is an hard thing to realize ?







Pigi

Years ago, in this forum was a huge Multilib flamewar started by Xynnox who wanted (or rather demanded) the abandon of 32bit Slackware and merging of Multilib on Slackware 64bit. With his main opponent being Darth Vader, who argued with him on 40+ pages threads. But there was interventions even from major players like Mr. Volkerding and Mr. Hameleers.

Looking back, in a nutshell, as I remember and I understand, the situation is this:

1. The fact that Slackware 64bit is a so called "pure 64bit operating system" and not Multilib, it's a operating system design decision considered and made by Mr. Volkerding when Slackware 64bit was invented, and merging Multilib will be a "fundamentally change" of operating system, which will never happen.

2. While it's not excluded that Slackware 32bit will be abandoned in a bright day, the abandoning of Slackware 32bit will mean also the end of Multilib support for Slackware 64bit, because Mr. Hameleers has no intention to maintain also a continuation/fork of 32bit Slackware.

I for one, I do not care about Multilib - in fact I have never used it in over 13 years of usage of Slackware 64bit, and I believe that the Multilib situation was over-clarified 5 years ago. Just I hope that people will understand that Multilib will never be merged in Slackware 64bit, because they (the Slackware Team, not me) do NOT want this.

In the end, 5 years later after that huge Multilib scandal, how everybody sees, nothing changed and Slackware 64bit is still a "pure 64bit operating system" .

In fact, the single thing "changed" is that Darth Vader got a lot of enemies because he was perceived as being "against" Multilib adoption - honestly I believe that he was just realist, not "against" it.

3 members found this post helpful.

Looked into it at some point, this would probably require a configuration file where one could decide which firmware gets cloned from git.
Patch for firmware SlackBuild is non issue, it's more of a the fact that everyone has different hardware and has to decide for themselves.
Since it's not realistic to expect each user to know which hardware requires which firmware and decide what to clone, it is now all in one package.
What I did was simply open the firmware package with "mc" and copy the files I use, because upgradepkg firmware takes 5min on my laptop.

Other distributions split the package kernel-firmware, but that means more maintenance work. However what could be easily done is compress the firmware files in the package. Here this gives an uncompressed package size of 330M, versus 789M for the genuine Slackware package.

1 members found this post helpful.

That is saving bandwidth for you, at the cost of everyone's installpkg using more CPU and RAM.
And the /x/ build system already fragments the stack into multiple tiny packages, without increasing CPU or RAM cost.

I just tried on Slackware 15.0 (I do not have Slackware-current installed at time of writing). Not exactly the same version but according "time installpkg":
not compressed: real 0m26,149s
compressed: real 0m11,457s

More CPU and RAM, really?

1 members found this post helpful.

"I just tried" without saying on what hardware means squat.
Just saying, 5 minutes upgradepkg kernel-firmware on 800.000 Mhz CPU and less than 1G RAM.
Few seconds on Ryzen with 32G and SSD, but whatever man. It costs more on old machines, and some CPUs don't even support extreme compression, that's all.

I miss Darth!
Every now and then I sense he might still be among us.

2 members found this post helpful.

Here you go, https://www.linuxquestions.org/quest...ml#post6409666

The reason it takes so much time is that you uncompress the txz package and get uncompressed firmware files on the disk. xz is slow.

But if the individual firmware files were compressed as Didier advocates, they would not be uncompressed by installpkg. They would stay compressed on the disk. That's why the "uncompressed package size of 330M, versus 789M". They only really get uncompressed at the moment some driver in the kernel wants to upload the firmware into some hardware device. Probable never, that is. Even if you have some hardware needing firmware, the individual files are very small, needing very little CPU time for the kernel to uncompress.

"That is saving bandwidth for you" is not quite correct. The Slackware txz packages are compressed tar files, and recompressing already compressed firmware data is not efficient bandwidthwise. Didier did not tell how the compressed package sizes compare, but the txz of compressed firmware would be larger than "the genuine Slackware package".

Even though the txz of compressed firmware would be larger, installing it would be a lot faster, because xz is fast to uncompress files which were not compressed at all (because they were already compressed once).

4 members found this post helpful.