I don't see WHY Master Of Slackverse want to introduce /lib64 and /usr/lib64 in a standard Linux tree.

In fact, even this concept of "lib64" thing was introduced to support the LinuxOnLinux thing aka multilib.

Hi,

Opinions are like a certain orifice, everyone has one. I for one believe the methodology that is utilized by PV and especially Alien_Bob for the way that x86_64 is implemented for Slackware is brilliant.

As a user you have the choice of x86_32 or x86_64 singular or by using multilib the user can have both. Your choice! If you happen to have a problem that doesn't work out for you then hopefully someone is able to resolve the issue thus helping others that may experience the same.
:hattip:

A great speach, thanks! :hattip:

BUT I talk about Slackware (aka the Slackware32?), so I don't see a common sense to introduce X86_64 directories in this Pure32 Linux. The Great P want to support the reverse multilib? A 32 bit operating system able to run 64 bit binaries? :D

Hi,

Why?

If you want VM then run one from the x86_64.

It's probably just that the developers are using a single unified base directory-tree to build the base package with, which would make a lot of sense.

Now granted, that means a 32bit system will have a couple of unnecessary ../lib64 directories cluttering the place up, but they're easily removed if you can't close your eyes and ignore them.

Personally, I'd have preferred the /lib and /lib32(for multilib) approach that some other distros decided to take, but at the same time I understand the arguments for using /lib and /lib64. I also preferred the /var/state/<package> directories that were in FHS2.0 over the /var/lib/<package> that they went back to in FHS 2.1 (or was it 2.1 and 2.2 I forget.), but I guess I just have to live with disappointment.

Gary is right. Sometimes opinions on how best to do something don't always agree with your own. Live with it.

btw I'm also using Alien Bob's mirror-slackware-current.sh script.

Somewhat straying from the thread, but still on-topic:

slackpkg is still at v2.81, however several bugfixes and the mirror updates have been released as v2.81.1. Are we expecting Pat to issue this at the point of release? I would have expected it to enter Slack pre-RC.

Thoughts?

It'll make it in =)

Check again.

Another shot of updates (including slackpkg). Thanks

Are we there yet?

Still we have the /lib64, /usr/lib64 and /usr/local/lib64 directories in the package aaa_base-13.1-i486-1.txz.

Ironically, a "build from source" create a correct package, without x86_64 things... ;)

Well, that blows my "maybe they're using a unified base directory-tree" idea out of the water. :)

Have you let Pat know? He may not spot every post in here.

How do I upgrade from 13.0 x86_64 to 13.1 RC1 64bit?

http://rlworkman.net/howtos/libata-switchover

I've used this method to upgrade from 13.0 to 13.1 RC1.
I hope that helps.

Thank you very much, Hitest!