LinuxQuestions.org - The steps likely required for upgrading Slackware to Slackware64.

- 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/)

I meant his name, not his message.

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.

Quote:

Originally Posted by jimX86 (Post 3559661)

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

Quote:

Originally Posted by jimX86 (Post 3559661)

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

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.

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.

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

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.

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

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

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

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!

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!

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.

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...