Incorporating multilib into base 13.1 install
in [Slackware]
|
From: Loki Harfagr on 18 May 2010 04:09 Tue, 18 May 2010 08:12:15 +0100, Peter Chant did cat : > Eric Hameleers wrote: > >> Peter Chant schreef: >>> Loki Harfagr wrote: >>>> there's a bit more, it'll imply reading quickly the 20 or 30 first >>>> lines of this page and do the two or three things like mkdir or cd >>>> without making a mistake about the name of the directory ;-) >>>> http://connie.slackware.com/~alien/multilib/ >>>> >>>> By the way, thank you very much Eric Hameleers for that piece of >>>> work. >>> >>> Indeed, the process is simple and flawless. Perhaps it could be >>> further scripted and added into mainstream slack? >>> >>> Pete >> >> This page describes the multilib upgrade process and the possibilities >> in detail: >> http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib >> >> > Yes, got that. Simple, easy to follow and quick. > >> And to answer the other question: Slackware64 will "forever" remain >> pure 64-bit. No multilib packages are planned in /extra either. > > Ah. Pity it can't go in extra, as going multilib is one of the first > things I do after installing. I wonder how common that is? you should start a poll on this :-) as for me, on 3 installations I only have 1 multilib and that's only because of my daughters and my job (read skype and CitriX ;-) I suppose I may need it too for some winXP emulators/virt/wine or some other loose end unsupported programs but the main ideai is not going multilib unless it is certain that "this special tool" is absolutely +needed+ *and* that the developers are either dead or worse and will never ever port it to 64 *and* that no other tool could replace or mimick "this special tool". All in all we all hope that things evolve so I'd bet multilib is about 1 fifth of installations while only really used once on twenty and in one to two years it _should_ reduce a lot ;-)
From: Robert Komar on 19 May 2010 03:50 Eric Hameleers <eric1(a)sox.homeip.net> wrote: > > This page describes the multilib upgrade process and the possibilities > in detail: > http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib > > And to answer the other question: Slackware64 will "forever" remain > pure 64-bit. No multilib packages are planned in /extra either. Do the multilib packages include *.h header files? If so, then that implies that the multilib files need to be the same version as the 64-bit packages currently installed. That would be a pain for me as I generally keep in sync with slackware64-current. The slamd64 32-bit compatability packages are for providing a run-time environment rather than a development environment, so keeping the 32-bit and 64-bit packages in sync isn't an issue. It would be good if the multilib stuff was as low-maintenance for use as a run-time environment. Cheers, Rob Komar
From: Eric Hameleers on 19 May 2010 15:04 Robert Komar schreef: > Eric Hameleers <eric1(a)sox.homeip.net> wrote: >> This page describes the multilib upgrade process and the possibilities >> in detail: >> http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:multilib >> >> And to answer the other question: Slackware64 will "forever" remain >> pure 64-bit. No multilib packages are planned in /extra either. > > Do the multilib packages include *.h header files? If so, then that > implies that the multilib files need to be the same version as the > 64-bit packages currently installed. That would be a pain for me > as I generally keep in sync with slackware64-current. > > The slamd64 32-bit compatability packages are for providing a > run-time environment rather than a development environment, so > keeping the 32-bit and 64-bit packages in sync isn't an issue. > It would be good if the multilib stuff was as low-maintenance > for use as a run-time environment. > > Cheers, > Rob Komar You are spewing unfounded opinions. The only true multilib packages are my rebuilds of the gcc and glibc that are in Slackware64, and mine replace the ones in Slackware64. The remainder of what you need to create a 32-bit compatibility layer on top of Slackware64 are a lot of 32-bit libraries and some binaries. These are provided by "-compat32" packages which are basically stripped and re-packaged 32-bit Slackware packages. They do not contain header files and other non-binary stuff because their 64-bit counterparts already provide those. If you have a need for 32-bit compatibility on Slackware64 then the software that has this requirement is usually not going to be anything very dynamic. Most likely you will need 32-bit libraries for some closed-source program (Citrix Client, and such) that you can not live without. Compiling 32-bit software on your multilib system should be a rare event, stuff like wine comes to mind but little else. Slackware64's multilib *is* low-maintenance. Eric
From: Ken P on 19 May 2010 15:15
On Wed, 19 May 2010 21:04:23 +0200, Eric Hameleers <eric1(a)sox.homeip.net> wrote: > The only true multilib packages are my rebuilds of the gcc and glibc > that are in Slackware64, and mine replace the ones in Slackware64. > > The remainder of what you need to create a 32-bit compatibility layer > on top of Slackware64 are a lot of 32-bit libraries and some binaries. > These are provided by "-compat32" packages which are basically > stripped and re-packaged 32-bit Slackware packages. They do not > contain header files and other non-binary stuff because their 64-bit > counterparts already provide those. > > If you have a need for 32-bit compatibility on Slackware64 then the > software that has this requirement is usually not going to be > anything very dynamic. Most likely you will need 32-bit libraries for > some closed-source program (Citrix Client, and such) that you can not > live without. Compiling 32-bit software on your multilib system should > be a rare event, stuff like wine comes to mind but little else. > > Slackware64's multilib *is* low-maintenance. > Eric, A great big thank you for providing multilib packages in a usable format so that people like me can use and enjoy. Thanks again. -- Ken P |