you can do it just set your tags on an install Did this years ago. stuff Eric's Multi Lib in it. I do this for my live slack for multi-lib. replace the gcc with Eric's then create a "ML" folder ad it to the install have fun. set your /etc/slackpkg/blacklist.

1 members found this post helpful.

I'm using slackpkg+ to keep multilib in sync and it works like a charm.

I get that Pat Volkerding probably wants Slackware64 to stay pure 64 bit. I just find it a bit odd that in order to be truly multilib ready, you have to go offsite of Slackware's main FTP server to download AlienBob's multilib gcc and glibc (and the multilib tools for any degree or sanity after that) - unless I want to go compiling and bootstrapping those myself (hint, I don't). Think about that from the perspective of someone unfamiliar with Slackware.

I'm not even suggesting they should be installed by default. Plop them into extra with the associated README files. Let people then convert the 32 bit packages to multilib themselves or go off and download slackpkg+, offsite... whatever the user chooses to do at that point.

That would still adhere to the Slack Way IMHO.

4 members found this post helpful.

coreutils-8.30:

http://git.savannah.gnu.org/gitweb/?...git;a=shortlog
http://ftp.gnu.org/gnu/coreutils/coreutils-8.30.tar.xz

guile-2.2.4:

http://git.savannah.gnu.org/gitweb/?...ads/stable-2.2
http://ftp.gnu.org/gnu/guile/guile-2.2.4.tar.xz

libinput-1.11.2:

https://cgit.freedesktop.org/wayland...?h=1.11-branch
https://www.freedesktop.org/software...-1.11.2.tar.xz

1 members found this post helpful.

xfsprogs-4.17:

https://git.kernel.org/pub/scm/fs/xf...s-dev.git/log/
https://www.kernel.org/pub/linux/uti...-4.17.0.tar.xz

1 members found this post helpful.

the problem with a pure 64 bit system is that it is incomplete since there is, and will be for some time, software that requires 32bit support.
we should have at least the compiler, and a base set of libs, per default available without depending on an external mirror

2 members found this post helpful.

I agree, it would seem best if those wanting wider multilib support only needed to add additional 32bit libraries rather than replace stock packages. Supplying in the base install both the multilib enabled compiler and a glibc-32 but nothing else 32bit seems like a sensible place to draw the line. But, perhaps Pat had a reason for drawing the line where he did?

2 members found this post helpful.

Agree that they are invaluable, but only if you want it. I rather have the option to have a pure 64 system and the ability to add multilib to that. I certainly do not want to go the opposite direction of having to remove multilib from a Slackware64 system.

How so? I agree that it will eventually come to pass, just disagree with the soon part. Of course that also depends on our definition of soon. Perhaps we agree.

Guess it depends on how you look at it. I don't see it as a problem. To me a pure 64-bit system is complete. If I find the need to install or compile 32-bit programs, then I can, thanks to Eric's multilib, easily add that capability or remove it.

I manually mirror Eric's multlib repository locally with a script that syncs on the parts I want (source and current only). I monitor ChangeLog.txt via RSS and run the script as needed. I use slackpkg+ to update my systems. I also have my own local repository of non-slack builds with a few additional compat32 packages. Except for two of my machines, all are pure 64-bit.

2 members found this post helpful.

I agree, there will be for some time, software that requires 32bit support.

That's exactly WHY, at least in my humble opinion, our BDFL still spends a consistent part of his valuable time to maintain and ship the Slackware 32-bit.

BUT, if we talk about the idea to dump the Slackware 32-bit in a partition where's already installed the Slackware x86_64, that I believe that's a pretty bad idea.

How nobody is perfect and everyone do mistakes, there I will agree with @Drakeo, that Eric Hameleers better to put the plug soon to his huge mistake named Multi-Lib, where he go against to very operating system design chosen by Patrick Volkerding.

Not that I care if this blasphemy is alive or not, but he misguide the Slackware users. As seen right on this very thread.

Because Slackware64 is a pure 64-bit system, then we should accept it as it is. Beyond the pure 64-bit Slackware is no Slackware anymore. That's AlienWare.

I use Slackware 32-bit (and I am rather devoted to) and I use Slackware64 as our BDFL seen proper to ship it: pure 64-bit. BUT I never felt the need to mix them, and I never felt that the x86_64 variant is "incomplete". Rather, both architectures ships the same software. Literally.

There are other ways to run a 32-bit distribution from a 64-bit one: LXC containers, for example.

I love the LXC containers because permit me to have clean and separate infrastructures, powered up as it is needed.

And from my own experience, the Slackware64 is pretty capable to run a full and literally complete Slackware 32-bit within a LXC container.

Oh, there's also the laziness and ego of some people...

I agree, the humans tend to be egoistic beasts, who see only their own interests and habits. Mine included - I am of the same species, after all.

1 members found this post helpful.

Agreed that they should not be installed by default. That's why I think the tools needed to get base multilib up and running (compat32-tools and multilib gcc/glibc) should either be put into extra or otherwise made optional, but be "official" in the sense that they be hosted on the main FTP server.

Personally I think the best case scenario would be to have an option in the installer asking if you want the base multilib system set up or not, but I'm not holding my breath for that.

sorry, but for all the people with the usual 'optional' argument, this makes no sense at all. we are not talking about a service or andy changes standard functionality.
If its there, you will not even notice that it is there. Nothing changes.
But you will notice if it is not there if you need it, since than you have a bad user experience.

Man, let's go back to roots again...

The choice between the support for a single architecture or for multiple architectures is the very basis and core of the operating system design, which Patrick Volkerding had to made while he was at the drawing table for Slackware64, long before its very birth.

And I am pretty sure that he was aware on that times about the Multi-Lib concepts, as there was Slamd64 (which was natively Multi-Lib), and also there was BlueWhite64 (which was a pure-64 port of Slackware). Then, he had the possibility to compare both implementations, and in very appropriate ways of Slackware, before to make a choice.

Then, many years later, you ask him now to change the fundamental design of that operating system. Which is wrong.

I believe that either you accept the Slackware64 as it is, or you to try to find a solution more appropriate to your needs.

1 members found this post helpful.

His bad user experience comes from his confusion of Slackware64 with something which is not.

And for these confusions there is also a particular marcant contributor to blame, in my humble opinion...

Fair enough. I wouldn't have a problem with it if it were NOT optional. I'm just trying to be diplomatic and come up with a potential compromise which may be more likely to be accepted by the community.

Based on the response so far it looks like I'm wrong, or at least people disagree. But that was the intention.

There are many projects which "dare to differ" from Patrick Volkerding philosophy, i.e. Spamware (Slackware + PAM) or Dlackware (Slackware + SystemD), then I think is OK for Eric Hameleers to "dare to differ" from the official "pure-64" point of view with his Multi-Lib.

But I think that does not make that Multi-Lib more legit to be merged in Slackware than Spamware or Dlackware, even I have nothing against to be merged all 3 of them.

2 members found this post helpful.

This is a little bit too much ... fundamental design of that operating system .... little bit way too much :-)
we are not talking about changing /lib64 to /lib or something fundamental that was an actual design decision, just some binaries different compiled and or additional available