Sure. One creative way to do that would be to modify SBO to allow for cross-compilation of SlackBuilds to 32-bit (if it doesn't already; I honestly haven't checked), and have compat32-tools step in and convert that compiled package into a *-compat32-* package. That way, the user could easily compile their own 32-bit software and libraries, and not have to rely on converting non-existent 32-bit binary packages.

HOWEVER, asking Slackware users to do that is one thing; asking them to cross-compile and bootstrap their own 32-bit versions of glibc and gcc is a bit much, even for some of the intermediate/advanced users.

If the cross-compiling of glibc and gcc is too much even for some of the intermediate/advanced users, makes sense to discuss about community maintaining a shadow 32-bit operating system which follows the one released by Patrick Volkerding?

And apparently the Slackware have a closed development model, where only the team have access.

I don't really understand what you're getting at and/or the point you're trying to make. Sure, people could, couldn't they. That is the beauty of free and open source software. Anyone could create a 32-bit fork at that point. There are many options, and there's more than one way to do it.

My point is that maintaing a Slackware 32-bit clone, identical with the Slackware64, for Multi-Lib purposes, may be much more complicated than cross-compiling glibc and gcc.

I agree, there are already many forks of Slackware.

But if the people who want Multi-Lib after Slackware 32-bit ends its life, if will end in forking Slackware, what the sense is to insist for certain features in Slackware64?

For example, they can fork the Slackware even right now, and to create a native Multi-Lib Slackware as they like, with both 32-bit and 64-bit packages, just like Fedora.

People, please stop dreaming!

Around there is only one man who have enough work power and knowledge to maintain a "shadow" Slackware 32-bit, IF/WHEN Patrick Volkerding will say EOL for it.

This man is Eric Hameleers and he certainly is not interested, from what I understand his statements.

Slackware 15 is not even out and they are talking about something unpredictable and far ahead in the future...

16-bit real mode forever! :-p

2 members found this post helpful.

To have an idea what will look the maintaining "your own Slackware 32-bit", take a look there: https://www.linuxquestions.org/quest...11-4175560702/

And the packages (and libraries) has dependencies and cross-dependencies, so I safely bet that most likely someone should maintain a real Slackware 32-bit distro, even it is for Multi-Lib purposes.

So, you love ELKS, aka Linux-8086? https://github.com/jbruchon/elks

Yeah, a really nice little thing that 16-bit Linux.

1 members found this post helpful.

Today you are fuller of shit than on any other day. Really, you should not post any more on my blog, you have depleted your karma and are no longer welcome there. New posts you make will be deleted.

Back on topic.
Remember that I created 64bit Slackware. Not Patrick. And when I created it, I edited every single SlackBuild script in the distro, creating them where missing (not every package was created by a .SlackBuild script back then) and made sure that every package would compile (some had not been recompiled for ages, nobodino will sympathize).
At the same time, ensuring that a single .SlackBuild would be able to compile a 32bit package, and a 64bit package, without modification. Thus not doubling Pat's burden by having to maintain two disjunct distros but enable him to build the two (32bit and 64bit) package trees out of one single source tree.

The "design" of 64bit Slackware was the result of a discussion between me and Pat and to some extent, the rest of the team. I wanted multilib out of the box, Pat wanted pure 64bit and we ended up in the middle where the 64bit Slackware is "multilib-ready" i.e. it is 64bit out of the box but a multilib sub-system is easily bolted on. Hence the "lib64" directories for instance.

Have the guts to show me exactly how I "misguide the Slackware users"? Why is a multilib Slackware no Slackware? Are you our new God and is this your latest Dogma?

17 members found this post helpful.

Well, at least these past few pages of drivel have resulted in no posts about PAM or systemd, so that brings a level of comfort.

As asked already at least once - this thread is to voice requests for Slackware -current. Any off-topic talk, move it to a separate thread please. If not, I will alert the moderators and ask them to handle this derailing.

6 members found this post helpful.

First, thank you Mr. Hameleers for the details about how was created and designed Slackware64. Very useful reading and I think everybody considered well your efforts.

But, keeping the religious themes, I understand that there are two saints, with two different dogmas.

From what I understand, Saint Patrick preaches pure 64bit, and looks like Darth Vader is one of his many followers. Forgive him for believing in that pure 64bit way.

But what statement makes Saint Eric, who preaches the multilib true way, to his followers who want right now this multilib merged in Slackware64? And that's on thread topic, because was raised that proposal.

You do not think that clear statements from the saints will help each ones believers to stop quareling about the differences on dogmas?

I believe it has been stated many times already, but the sins keep coming back....
oh well...

2 members found this post helpful.

I asked Mr. Hameleers for a statement about the requested merge of multilib in Slackware64.

I think my question is on-topic, considering the last several pages of this thread.

You asked. Good job. If Patrick likes your idea, he will implement it. Now move on.

Yes exactly. As awesome as AlienBob is (and he is truly awesome) he does not directly represent Slackware.

I'd like to thank AlienBob for providing the history as well.

If I'd known it would start this much of a flame-fest, I never would have brought it up.

3 members found this post helpful.