LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   The steps likely required for upgrading Slackware to Slackware64. (https://www.linuxquestions.org/questions/slackware-14/the-steps-likely-required-for-upgrading-slackware-to-slackware64-727671/)

Shingoshi 05-21-2009 08:34 PM

The steps likely required for upgrading Slackware to Slackware64.
 
I think the first step for anyone wanting upgrade to Slackware64, is to FIRST install the 64-bit kernel. If for any reason the rest of the installation fails, you will still be able to boot your system. However, if you still have a 32-bit kernel installed and try to install the Slackware64 glibc, you will have lost your system. This wouldn't be permanent though. You would simply have to use an installation disk to correct the problem. So here's what I think should be a safe course of action:

Wait until the release of Slackware64-13.0!!
Keep in mind, this is the only way to be able to run any 32-bit applications.
1.) Download and have ready the packages from Slackware64/a
2.) Download and have ready all of the ia32-packages from Bluewhite64.
http://mirror.inode.at/data/bluewhit...a32-emulation/
3.) Install the 64-bit kernel, along with the kernel modules.
4.) Reboot your system into the 64-bit kernel.
5.) Install the 64-bit glibc.
6.a) If you're still able to run your system, finish the update of other packages.
7.) Now install the Bluewhite ia32-packages.
6.b) If you wind up stopped at step #5, reboot your system. After reboot, the new glibc should be in use.
8.) Install and test any other packages.
9.) If you're unable to run the new glibc on the 64-bit kernel, you'll need to use an installation disk.

If you encounter the condition at step #9, do this:
1.) Boot your system using the installation disk.
2.) Mount your root partition, and any other partitions required for installation.
3.) Chroot into your root partition, and "cd /anywhere/you/have/your/packages.
3.a) Alternatively, you may run setup, select your root partition and bypass the disk format of course.
4.) Upgrade existing system packages.

Shingoshi

joutlancpa 05-21-2009 10:08 PM

Quote:

Originally Posted by Shingoshi (Post 3548772)
I think the first step for anyone wanting upgrade to Slackware64, is to FIRST install the 64-bit kernel. If for any reason the rest of the installation fails, you will still be able to boot your system. However, if you still have a 32-bit kernel installed and try to install the Slackware64 glibc, you will have lost your system. This wouldn't be permanent though. You would simply have to use an installation disk to correct the problem. So here's what I think should be a safe course of action:

Wait until the release of Slackware64-13.0!!
snip....
>=(o_O)=>

That pretty much sums it up for me :)

XGizzmo 05-21-2009 10:24 PM

I think it is reckless to post a how to for something like this that will almost surly break your system.
And to top it off it sounds as if you have not even tried this yourself. Why even start people down a path
that will likely end in disaster?

Shingoshi 05-22-2009 03:55 PM

Changing the order of one step!!
 
Quote:

Originally Posted by Shingoshi (Post 3548772)
I think the first step for anyone wanting upgrade to Slackware64, is to FIRST install the 64-bit kernel. If for any reason the rest of the installation fails, you will still be able to boot your system. However, if you still have a 32-bit kernel installed and try to install the Slackware64 glibc, you will have lost your system. This wouldn't be permanent though. You would simply have to use an installation disk to correct the problem. So here's what I think should be a safe course of action:

Wait until the release of Slackware64-13.0!! [As presently proven, this is no longer required!!]
Keep in mind, this is the only way to be able to run any 32-bit applications.
1.) Download and have ready the packages from Slackware64/a
2.) Download and have ready all of the packages in Bluewhite64 extra/ia32-emulation/
http://mirror.inode.at/data/bluewhit...a32-emulation/
3.) Install the 64-bit kernel, along with the kernel modules.
4.) Reboot your system into the 64-bit kernel.
This is the reordered step:
7.) Now install the Bluewhite64 ia32-packages.

5.) Install the 64-bit glibc.
6.a) If you're still able to run your system, finish the update of other packages.
6.b) If you wind up stopped at step #5, reboot your system. After reboot, the new glibc should be in use.
8.) Install and test any other packages.
9.) If you're unable to run the new glibc on the 64-bit kernel, you'll need to use an installation disk.

If you encounter the condition at step #9, do this:
1.) Boot your system using the installation disk.
2.) Mount your root partition, and any other partitions required for installation.
3.) Chroot into your root partition, and "cd /anywhere/you/have/your/packages.
3.a) Alternatively, you may run setup, select your root partition and bypass the disk format of course.
4.) Upgrade existing system packages.

Shingoshi
>=(o_O)=>

It should be noted that I'm changing only one step here. But that step is likely very consequential. I believe you need to install the ia32 packages from Bluewhite64 BEFORE upgrading your existing glibc from Slackware. As I believe the 32-bit glibc will still be needed during the upgrade of your remaining packages. But you still need to install the 64-bit kernel and REBOOT FIRST!!

After having installed the ia32 packages, I was able to upgrade my running Slackware system, since the ia32 glibc is kept in /lib32. That prevents it from being overwritten during the upgrade process.

Shingoshi 05-22-2009 04:18 PM

I've already done this going from Slackware to Slamd64...
 
Quote:

Originally Posted by XGizzmo (Post 3548836)
I think it is reckless to post a how to for something like this that will almost surly break your system.
And to top it off it sounds as if you have not even tried this yourself. Why even start people down a path
that will likely end in disaster?

There's nothing about this that is presumed. I've already have experience upgrading a running Slackware system to Slamd64. The main reason why I said LIKELY steps, is because I didn't try this from "Slackware to Slackware64". If the only difference between Slackware64 and Slamd64, is Slackware64's omission of the 32-bit compatibility layer, you need to install it first. Because Slamd64 already had that layer as part of their system, I didn't have to go to extra steps to get it. It was already included as part of the process in upgrading.

I am now in the process of verifying that there should be no problems here. I've already had (samac's) confirmation that the Slamd64 32-bit layer works. The only question I have now is whether it can be installed to replace your existing and running Slackware glibc, without trouble caused by it.

Shingoshi
>=(o_O)=>

Shingoshi 05-22-2009 05:53 PM

I've just been advised by Fred Emmott (the Slamd64 creator), that there will likely be issues of incompatibility with the Slamd64 32-bit packages. That seems to increase the need for having packages built exclusively for Slackware64, and not depend on any other packages from other distributions.

Slackware64 will need it's own 32-bit compatibility layer.

Shingoshi
>=(o_O)=>

samac 05-22-2009 06:52 PM

I would have thought that upgrading a system from 32 bit to 64 bit was a fools errand. Surely it would be much easier and safer to do a fresh install and just keep your old /home partition.

samac

rworkman 05-22-2009 07:01 PM

I HAVE upgraded a system from slackware-current (32bit) to slackware64-current (partly out of curiosity, and partly so I could speak more authoritatively on the matter), and I can say with 100% certainty that you will need the installation disk if you try to upgrade following these steps, and if that's the case, you may as well just boot the installer and use:
Code:

ROOT=/mountpoint/of/slackware32 upgradepkg --reinstall --install-new /path_to/slackware64/*/*.t?z
and then chroot into that to fix up lilo and remove irrelevant packages.

I originally decided NOT to post a howto on this, if only to avoid having (answer|ignore) emails about problems encountered with it. However, since this is already out there, here's the short version:

You have to keep a 32bit libc around, as well as any 32bit libraries being used by any 32bit binaries you're running, for as long as they're (planning to) be(ing) used. If you don't understand what that means and how to make sure it happens, then don't try a live upgrade - there's no good reason to do it anyway.

Shingoshi 05-22-2009 08:10 PM

Thank you for the further clarification!!
 
Quote:

Originally Posted by rworkman (Post 3549776)
I HAVE upgraded a system from slackware-current (32bit) to slackware64-current (partly out of curiosity, and partly so I could speak more authoritatively on the matter), and I can say with 100% certainty that you will need the installation disk if you try to upgrade following these steps, and if that's the case, you may as well just boot the installer and use:
Code:

ROOT=/mountpoint/of/slackware32 upgradepkg --reinstall --install-new /path_to/slackware64/*/*.t?z
and then chroot into that to fix up lilo and remove irrelevant packages.

I originally decided NOT to post a howto on this, if only to avoid having (answer|ignore) emails about problems encountered with it. However, since this is already out there, here's the short version:

You have to keep a 32bit libc around, as well as any 32bit libraries being used by any 32bit binaries you're running, for as long as they're (planning to) be(ing) used. If you don't understand what that means and how to make sure it happens, then don't try a live upgrade - there's no good reason to do it anyway.

That's why I edited my previous comments above. It really occurred to me that the 32-bit libraries would still be needed during the upgrade.

Shingoshi
>=(o_O)=>

I'm adding this for everyone to read. Make sure you read this. It's IMPORTANT!!
http://www.linuxquestions.org/questi...00#post3549800

Petri Kaukasoina 05-23-2009 05:48 AM

Quote:

Originally Posted by rworkman (Post 3549776)
If you don't understand what that means and how to make sure it happens, then don't try a live upgrade - there's no good reason to do it anyway.

I had a reason: I was not near the computer, so on Thursday I did the upgrade via a ssh connection. Running a 64-bit kernel, user level 3, I first installpkg'd glibc and aaa_elflibs, then installpkg'd everything -x86_64- in A and L series, then upgradekpg'd other packages (should have used upgradepkg --reinstall) from all series, rebooted, removepkg'd *[3456]86* packages. (Afterward I noticed that also the -noarch- packages had stuff at changed paths, but with unchanged package names, so I had to upgradepkg --reinstall them.)

gargamel 05-23-2009 07:16 AM

...sorry, just noticed, someone else posted something similar already...

Shingoshi 05-23-2009 11:36 PM

Take these and call me in the morning!!
 
The method that I used to upgrade to Slackware64, was to first install the ia32-pkgs from Bluewhite64.
http://mirror.inode.at/data/bluewhit...a32-emulation/
I did that before I did anything else. I'm going to edit my post above to make sure there is no confusion.

Shingoshi
>=(o_O)=>

Shingoshi 05-24-2009 10:26 PM

How much more needs to be said. The solution ALREADY existed!!
 
Actually, I'm running Firefox in Wine right now. Need I say anymore? And no, this IS Slackware64, albeit, with real multilib now!

Shingoshi
>=(o_O)=>

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 - Build ID: 2009042316

Edit: And I have since upgraded Firefox in Wine!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre - Build ID: 20090601044045

Shingoshi 05-31-2009 04:38 PM

After having followed my own instructions on two separate computers, I can tell all users, there is NO further need to wait until Slackware64 is released to the public. Just make sure you have the Bluewhite64 ia32-packages installed BEFORE changing your glibc!

http://mirror.inode.at/data/bluewhit...a32-emulation/

Shingoshi

rworkman 05-31-2009 05:42 PM

There is absolutely no need to install *anything* from BlueWhite64 in order to make the upgrade, and anyone who says otherwise should be ignored.

Shingoshi 05-31-2009 06:29 PM

A matter of reflection...
 
It could be noted, that before any of my original posts about a means for running 32-bit applications on Slackware64, there was no solution. It was only after I first mentioned using Slamd64 32-bit compatibility packages, and having that initially discouraged, that NEW packages were then created to allow 32-bit binaries to run on Slackware64. First came the multilib rebuild of gcc for Slackware64. And now comes the 32-bit compatibility packages rebuilt (by the same author) against Slackware64. Neither of these facts existed before I said anything about them. And it seems they were only created in response.
Quote:

The major difference between these two sets of packages, is where they are placed on disk.
Bluewhite64: /lib32 & /usr/lib32
Slackware64: /lib & /usr/lib

The difference is the absolute security that nothing can ever overwrite your 32-bit libraries. NEVER!! This is important if you ever compile your own packages, and for any reason the suffix for lib64 is not explicitly stated. If that ever happens, you will be out of luck. It's just like having your 32-bit libraries in a sandbox.
But as always, every user is allowed their own choice.

Shingoshi

rworkman 05-31-2009 06:52 PM

Quote:

Originally Posted by Shingoshi (Post 3558406)
It could be noted, that before any of my original posts about a means for running 32-bit applications on Slackware64, there was no solution. It was only after I first mentioned using Slamd64 32-bit compatibility packages, and having that initially discouraged, that NEW packages were then created to allow 32-bit binaries to run on Slackware64. First came the multilib rebuild of gcc for Slackware64. And now comes the 32-bit compatibility packages rebuilt (by the same author) against Slackware64. Neither of these facts existed before I said anything about them. And it seems they were only created in response.

Speaking of predictions:

http://www.linuxquestions.org/questi...60#post3547660

http://www.linuxquestions.org/questi...65#post3548265

Martinezio 06-01-2009 09:29 AM

So, what's the final path to _proper_ distro-upgrade?

I have currently downloaded a dvd iso-image built on May the 26th by slackware.no team...

I have some software built for my own way from sources and I want them working... Should I or not install those 32-bit compat pack?

Alien Bob 06-01-2009 10:03 AM

First off: the http://slackware.no team is not affiliated with Slackware. Their ISO images are unofficial.

Second: Slackware64 has no official release yet - it is available as "slackware64-current" meaning it is a development tree. If you want to use a -current tree of Slackware, you are regarded as a beta tester, and you are expected to find your way around any breakage (of course, there are many helpful people here on LQ and the ##slackware IRC channel at Freenode when things do break). Only an upgrade between two adjacent official release versions is supported with official documentation on the DVD/CDROM (UPGRADE.TXT and CHANGES_AND_HINTS.TXT).

Having said all that, you'll find that slackpkg (contained in Slackware's "AP/" series) is very well capable of upgrading Slackware for you. You will have to read its documentation before you attempt this! It is a largely automated process but you remain in control and have to make several important decisions in the course of the upgrade.

My advice is to upgrade to the most recent version of slackpkg before using it.

Eric

Shingoshi 06-01-2009 02:19 PM

The best solution is the one that works...
 
Quote:

Originally Posted by Martinezio (Post 3559002)
So, what's the final path to _proper_ distro-upgrade?

I have currently downloaded a dvd iso-image built on May the 26th by slackware.no team...

I have some software built for my own way from sources and I want them working... Should I or not install those 32-bit compat pack?

If you attempt to install any packages (except the 64-bit kernel) without having installed the ia32 compatibility layer, your system will become unusable, and will NOT complete the upgrade. You absolutely must install the ia32 compatibility packages to upgrade a running system without any problems. Glibc is the most important package of all. You must have a 32-bit replacement for it during an upgrade to 64-bit.
Quote:

Originally Posted by ROXR (Post 3558839)
I installed the anorien.warwick.ac.uk 32 bits library, but applications return an error of "Segmentation fault"

May be some advance with the Bluewhite64 32 bits librarys ?

thanks

If you install these packages (http://mirror.inode.at/data/bluewhit...a32-emulation/), and you don't like them, you can always remove them. I think the reason why the above user may have had trouble, is precisely because he installed the Slamd64 packages which go in /lib and /usr/lib. You simply cannot do that to your running glibc, since it will likely overwrite it. You can only install the Slamd64 packages AFTER the system has already been successfully upgraded. The Bluewhite64 packages can and should be installed to a running Slackware system, WITHOUT any chance of anything being corrupted in the process.

I personally have suggested the use of the Bluewhite64 ia32 packages. Some are strongly opposed to doing so. But as I've stated in my posts, I've had no problems with the Bluewhite64 packages. I've performed live upgrades of two separate systems using them. All of my 32-bit packages that can still find the libraries they were built against, still work. There are a few which I have personally built, like the tools for my Logitech G15 keyboard which needs to be updated. But for the most part, everything is as it should be.

Find a solution that works and keep it.
Shingoshi

rworkman 06-01-2009 04:29 PM

Quote:

Originally Posted by Shingoshi (Post 3559320)
If you attempt to install any packages (except the 64-bit kernel) without having installed the ia32 compatibility layer, your system will become unusable, and will NOT complete the upgrade. You absolutely must install the ia32 compatibility packages to upgrade a running system without any problems.

Except you're wrong.

rworkman 06-01-2009 04:31 PM

As the primary author of CHANGES_AND_HINTS.TXT, let me assure everyone that we WILL have upgrade instructions.
I can also assure you that the reason is not because Shingoshi has suggested that they are needed.

Shingoshi 06-01-2009 04:45 PM

It may be safe to install any packages other than the 64-bit glibc without having replacements for those packages in place. But I don't see any point in advising anyone to take any course of action that may leave them with the possibility of forgetting to install the 32-bit replacement glibc. Only to have them wondering why they don't have use of their 32-bit packages.

And it should be noted for anyone reading this thread, what the results have been with using any packages other than Bluewhite64's ia32 compatibility layer.As I've stated. Anyone is free to do anything they want. They are also free to live with the consequences of their choice.

If it doesn't work, it can't be right.
Shingoshi

Alien Bob 06-01-2009 05:04 PM

Quote:

Originally Posted by Shingoshi (Post 3559477)
They are also free to live with the consequences of their choice.

If it doesn't work, it can't be right.
Shingoshi

So very to the point, this.

Apparently you do not live up to your own dogma Shingoshi. Why else all these posts where you try to put the blame for your failures with others?

Eric

Shingoshi 06-01-2009 05:44 PM

Interesting! My 32-bit packages work just fine! If they weren't, I wouldn't have been able to type in this forum, using Firefox in Wine.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre - Build ID: 20090601044045

Thanks to Bluewhite64...
Shingoshi

Shingoshi 06-01-2009 06:31 PM

This needs to be explicitly stated. There can be NO OFFICIAL statement made to encourage or discourage any person from using ANY set of tools to provide 32-bit compatibility in Slackware64, until Slackware64 has been OFFICIALLY released. And in the event that Slackware64 is released without it's own 32-bit compatibility layer, there can still be NO OFFICIAL statement made about any set of packages any user chooses to use. The fact that someone has (re)built packages based on Slamd64, still doesn't give them OFFICIAL status.

User Be Aware.
Shingoshi

brianL 06-01-2009 06:57 PM

What does Shingoshi mean? I'm guessing something like "opinionated bore", but I could be wrong.

titopoquito 06-01-2009 07:20 PM

Quote:

Originally Posted by brianL (Post 3559623)
What does Shingoshi mean? I'm guessing something like "opinionated bore", but I could be wrong.

You don't really think there is ANY reasonable amount of words to explain what Shingoshi's OFFICIAL message here is? Since he is not able to explain himself in two or three (dozen) posts, who else should? LIKELY no one ;)

Alien Bob 06-01-2009 07:22 PM

I've never made any official statements. Simply because I have no official status. But I can voice my opinion about the wisdom of certain actions. There is nothing more to it, really.

Eric

onebuck 06-01-2009 07:24 PM

Hi,
Quote:

Originally Posted by Shingoshi (Post 3559603)
This needs to be explicitly stated. There can be NO OFFICIAL statement made to encourage or discourage any person from using ANY set of tools to provide 32-bit compatibility in Slackware64, until Slackware64 has been OFFICIALLY released. And in the event that Slackware64 is released without it's own 32-bit compatibility layer, there can still be NO OFFICIAL statement made about any set of packages any user chooses to use. The fact that someone has (re)built packages based on Slamd64, still doesn't give them OFFICIAL status.

User Be Aware.
Shingoshi

Why do you keep trying to p^ss up a rope? People are free to do what they want with their systems. Either run a pure 64 or break it.

Your continued tirade is getting absurd. There's nothing wrong with you attempting to break your system but to encourage others to attempt things on a'-current' system is irresponsible.

Your open disclosure should include coverage for your suggestions.

Be it official or a '-current' OS, your argument is moot. I'm being polite since I don't want anything rubbing off from you.

I see no reason for you too stop your experimentation but please don't degrade others for not feeling the same. Go ahead and do what you want but remember this is still a '-current'. So why create more problems by creating a sickly system by your methods.

brianL 06-01-2009 07:39 PM

I meant his name, not his message.

jimX86 06-01-2009 07:41 PM

Might I suggest going to "My LQ" and selecting "Edit Ignore List"? I've never actually done that before, but it turns out to be a wonderful thing. I'm all fired up about Slackware64 and would like to learn more, but all this drama is too much for me.

mlangdn 06-01-2009 08:18 PM

Quote:

Originally Posted by jimX86 (Post 3559661)
Might I suggest going to "My LQ" and selecting "Edit Ignore List"? I've never actually done that before, but it turns out to be a wonderful thing. I'm all fired up about Slackware64 and would like to learn more, but all this drama is too much for me.

That is a useful thing - that ignore list.
I need to explore a bit more.

niels.horn 06-01-2009 09:00 PM

Quote:

Originally Posted by jimX86 (Post 3559661)
Might I suggest going to "My LQ" and selecting "Edit Ignore List"? I've never actually done that before, but it turns out to be a wonderful thing. I'm all fired up about Slackware64 and would like to learn more, but all this drama is too much for me.

I had never used the ignore list before. But Shingoshi made it necessary.
Ignoring him saves me precious time.

Franklin 06-01-2009 09:41 PM

Quote:

Originally Posted by niels.horn (Post 3559715)
I had never used the ignore list before. But Shingoshi made it necessary.
Ignoring him saves me precious time.

It's hard to disagree with the benefits of ignoring these posts.

Unfortunately, I suspect that when Slackware64 is released as stable, much of this "advice" will either be irrelevant or flat out wrong (if it isn't already). New Slackware users may find themselves dealing with frustrations they would not have had to otherwise had the signal-to-noise ratio been more favorable.

I would hope that if any of this "advice" does eventually turn out to be "ill-advised", that these threads would be closed to hopefully prevent people from borking their system.

onebuck 06-01-2009 09:48 PM

Hi,

I think future users of this thread will have enough arguments within that advice against some of the before mentioned advice. So users beware! Read the WHOLE thread.

Shingoshi 06-02-2009 12:59 AM

I would be absolutely happy to be wrong, IF:
1.) Slackware64 ships with a fully operational multilib environment.
2.) They provide a complete 32-bit compatibility environment in the stock release.
3.) You can easily compile 32-bit applications.

Yes, I would be absolutely happy to be wrong.
And then none of this would make any sense (http://www.linuxquestions.org/questi...30#post3559330).
And PatV's interview can simply be thrown out as empty chatter:
http://tllts.org/mirror.php?fname=tl...4-10-25-06.mp3

Yes, please make me wrong...
Shingoshi

Martinezio 06-02-2009 02:04 AM

Ok, thanks for the advice, Eric :) I forgot to mention, that I'm using slackware-current distro, so I am a beta tester ;)

What I'm asking for is not the official standing and recipe, but only a path, that You will use to do this upgrade.

Shingoshi 06-02-2009 02:11 AM

Some things don't need to be set in stone...
 
Standards are most often used to establish a level appropriate equivalency in environments that tend to be dissimilar.

As far as FHS standards go, the following groups have already abandoned it:
Ubuntu
Gentoo
FreeBSD

http://lists.debian.org/debian-relea.../msg00144.html
Quote:

So there really is no way to comply with the current FHS on amd64 without
some serious package special-casing. That makes /emul/ia32-linux vs.
/usr/lib32 entirely a question of aesthetics, not standards-compliance.

Quote:

Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port compliant with the FHS, which is almost impossible given the current setup, ie 64-bit libraries in /lib. However, it would make it compliant with the part of the FHS which says that alternative libraries have to be in (/usr)/lib<qual>. And it would make us compatible with other distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32.
http://lists.debian.org/debian-relea.../msg00158.html
Quote:

You have been heard! The glibc currently in incoming has a preliminary
multiarch support. It currently looks to librairies in both (/usr)/lib
and (/usr)/lib/$(host-triplet)/. It support additional libraries (like
the current one in multilib), via ldconfig, with /lib/ldconfig/ being
the configuration directory.

Using this it will be possible to add a link from (/usr)/lib64 to the
multiarch directories to be compliant with the FHS. And that let time to
discuss if we want a (/usr)/lib32 or not on amd64 :).

Currently those directories are supported on all architectures, but only
amd64 has files in them, a libc6 for i386. It will be used as a test
architecture before doing the same on other 32/64 bit architectures, as
there are very few packages to changes.

The next step is to add support to gcc, and to move all 32-bit libraries
on amd64 to (/usr)/lib/i486-linux-gnu.

I will send you some update and some patches for gcc, zlib (needed for
gcc) and ia32-libs soon.

Bye,
Aurelien
This is a topic having been and still being debated as to the best course of action in light of new technologies. Technologies that sometimes weren't even considered at the time the standards were formulated.

http://lists.debian.org/debian-relea.../msg00168.html
Quote:

Here is my opinion:
Advantages

- Coherency between ports. MIPS will use /usr/lib32 when the tri-arch patch will be finished, the unofficial ppc64 pot uses /usr/lib32. Also this is the counterpart of /usr/lib64 on other arches. - Easier for biarch package maintainers, as they don't need to do special things for amd64. This is essentially true for the glibc. - /usr/lib32 is a search path for gcc /emul/ia32-linux/usr/lib is not, that's why we currently have a symlink.
Quote:

> The Linux File Hierarchy Standard FHS Version 2.2 final
> (http://www.pathname.com/fhs/) supports both file location
> and naming conventions for such libraries: /lib32 and /lib64
> to place 32bit and 64bit libraries.

So far I was with you, but the names lib32 and lib64 are *examples*,
the FHS supports:

/lib<qual> and /usr/lib<qual>

where the list of qualifiers is undefined.
I guess if the intention is to limit the number of official ports, many of the concerns for the explicit separation of libraries will never be discussed.

Shingoshi

samac 06-02-2009 04:55 AM

Shingoshi, whilst your arguments are obviously very important to you, I feel you are missing the point completely. Slackware64 is developed by an extremely small group, who will release what they want, when they feel it is ready. If they choose to have 32-bit compatibility they will include it. If they don't they won't.

All you need to look at is the example of Gnome for both the answer and the solution. If you are so bothered by this work on patches to the system and offer them for acceptance. If they are taken up all is good and well, if not you can offer them as a separate entity.

There is no use complaining about something if you are not willing to do something about it.

samac

brianL 06-02-2009 07:20 AM

If you all put Shingoshi on on your ignore lists, then who is going to protect newbies from being misled by his advice?

GazL 06-02-2009 07:58 AM

Quote:

Originally Posted by Shingoshi (Post 3559930)
I guess if the intention is to limit the number of official ports, many of the concerns for the explicit separation of libraries will never be discussed.

Your concerns for the explicit separation of libraries don't need discussing. 64bit libs go in [/usr]/lib64, 32bit libs go in [/usr]/lib as described in the FHS. Seems pretty separate to me. No further discussion necessary.

I also don't see how this would limit any potential ports. You seem to be finding problems where non exist.

I'm torn between the desire to put you on ignore and the need of calling 'bullshit!' when I see it. As brianL says, newbies have enough to worry about when getting to grips with slackware without having to try and see through all this misinformation and FUD!

hitest 06-02-2009 08:40 AM

Quote:

Originally Posted by GazL (Post 3560222)
I'm torn between the desire to put you on ignore and the need of calling 'bullshit!' when I see it. As brianL says, newbies have enough to worry about when getting to grips with slackware without having to try and see through all this misinformation and FUD!

I think it is important for newcomers to our site to know who they can trust. Over the years I have learned to completely trust the Slackware developers who take time out of their busy schedules to also post here and help newcomers to Slackware. Robby, Eric, and the entire Slackware team provide accurate information for newcomers to Slackware. If a member has the label "Slackware Contributor" under their username then you can completely trust their advice.
Also, there are a number of Master Slackers like gnashley and onebuck who will not steer you wrong. Over time a new Slacker will identify other mentors that they can trust.
Agreed. FUD is something a new user can do without!

onebuck 06-02-2009 08:58 AM

Hi,

The sky is falling! :(


The sky is falling! :(


The sky is falling! :(

Hopefully this thread will shrink and disappear?

Slackware64 -current; The concurrence of Slackware -current in a 64 bit environment port;

Quote:

excerpt from Slackware64 Released
[Posted May 20, 2009 by ris]
;

Ready or not, Slackware has now gone 64-bit with an official x86_64
port being maintained in-sync with the regular x86 -current branch.
DVDs will be available for purchase from the Slackware store when
Slackware 13.0 is released. Many thanks go out to the Slackware team
for their help with this branch and a special thank you to Eric
Hameleers who did the real heavy lifting re-compiling everything for
this architecture, testing, re-testing, and staying in-sync with
-current.

We've been developing and testing Slackware64 for quite a while. Most
of the team is already using Slackware64 on their personal machines,
and things are working well enough that it is time to let the community
check our work.

We'd like to thank the unofficial 64 bit projects for taking up the
slack for us for so long so that we could take our time getting
everything just right. Without those alternatives, we would have been
pressured to get things out before they were really ready.

As always -- have fun!

Pat and the Slackware crew

It cannot be clearer. The above notice by PV provides the answers to questions or errors within this thread.

Linux.tar.gz 06-02-2009 10:04 AM

Please, stop all this mess and wait 'til the final release.
I'm sure we will have a nice UPGRADE.txt, althought i think reinstalling from scratch is a more clever choice.
Then we will find plenty of ways to run 32bit apps (scripted chroot, kvm/qemu...).
Or not !!! I mean running a 64bit system is not mandatory, it's just an optimization. Until now, Blender 64 is the only program i saw running
twice faster than 32bit version...

Martinezio 08-28-2009 05:44 AM

Well, Slackware 13 is finaly released as stable.
Where can I find this UPGRADE.txt notice? ;) Is it ready, or not yet?

brianL 08-28-2009 05:58 AM

See this thread:
http://www.linuxquestions.org/questi...are-13-750816/

Martinezio 08-28-2009 06:07 AM

Ok, I found it, thx.
But note from CHANGES_AND_HINTS.txt:
Quote:

*** INSTRUCTIONS FOR UPGRADING FROM 12.2 ***
(snip)
Also note that upgrading from 12.2 to 13.0 (64bit) is not supported.
But how about upgrading from -current x86 to 64-bit? It's rater switching between platforms than upgrading...

I know, that the best way is to reinstall from scratch, but I don't have any available disks to make backup of my files and data.
If I install from scratch OVER existing installation without re-formating the drive, is it possible to keep my data secure?

tomtomjkw 08-28-2009 03:36 PM

Buying and burning dvd or copying to pendrive or similar would be safest way. Next time you make fresh install, consider creating two partitions - one mounted as / , second as /home. That way you only have to take care of your /etc directory when making another fresh install.

onebuck 08-29-2009 08:28 AM

Hi,
Quote:

Originally Posted by Martinezio (Post 3660596)
Ok, I found it, thx.
But note from CHANGES_AND_HINTS.txt:

But how about upgrading from -current x86 to 64-bit? It's rater switching between platforms than upgrading...

I know, that the best way is to reinstall from scratch, but I don't have any available disks to make backup of my files and data.
If I install from scratch OVER existing installation without re-formating the drive, is it possible to keep my data secure?

You could shrink or move partition files to a temporary space. This would depend on your hdd configuration. If you have a primary allocation left with some space then you could create a filesystem on this. If not then hopefully you have the means to juggle the space on your available hdd by shifting space inward and moving the partition. Either by using another primary or creating a extended to have logical partition(s). Take a look a qparted.


All times are GMT -5. The time now is 05:41 PM.