From tilman at crux.nu Sat Jun 21 09:47:29 2008 From: tilman at crux.nu (Tilman Sauerbeck) Date: Sat, 21 Jun 2008 11:47:29 +0200 Subject: [crux64] [crux-devel] 64-bit test run In-Reply-To: <485C4593.7040906@gmail.com> References: <485C4593.7040906@gmail.com> Message-ID: <20080621094728.GB1269@code-monkey.de> Bartek Palmowski [2008-06-21 02:04]: > crux64 looks promissing, and I'd me more than happy if I could help > with project. I already have done some initial testing and must say crux > for 64 bit processors is in demand. If I may suggest an idea to add > variable to pkgmk.conf like ie. ARCH_HOST=64, which would make easier > "architecture type" extraction. What were playing with atm are separate ports trees for x86_64. So opt-x84_64/foo/Pkgfile will only be used on x86_64 and so there's no need to check the current architecture etc. I guess I should document the layout I have in mind in the wiki? Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wszystkie.fajne.loginy.zajete at gmail.com Sat Jun 21 15:55:37 2008 From: wszystkie.fajne.loginy.zajete at gmail.com (Bartek Palmowski) Date: Sat, 21 Jun 2008 17:55:37 +0200 Subject: [crux64] crux64 Digest, Vol 7, Issue 1 In-Reply-To: References: Message-ID: <485D2479.5050207@gmail.com> > > Hi > > > > crux64 looks promissing, and I'd me more than happy if I could > > help with project. I already have done some initial testing and must > > say crux for 64 bit processors is in demand. If I may suggest an idea > > to add variable to pkgmk.conf like ie. ARCH_HOST=64, which would make > > easier "architecture type" extraction. > > > > > Why would that be a good idea? Because we could use one ports tree instead of two, which would be easier to maintain. regards Bartek Palmowski From tilman at crux.nu Sat Jun 21 17:27:02 2008 From: tilman at crux.nu (Tilman Sauerbeck) Date: Sat, 21 Jun 2008 19:27:02 +0200 Subject: [crux64] crux64 Digest, Vol 7, Issue 1 In-Reply-To: <485D2479.5050207@gmail.com> References: <485D2479.5050207@gmail.com> Message-ID: <20080621172701.GA22276@code-monkey.de> Bartek Palmowski [2008-06-21 17:55]: > > > > Hi > > > > > > crux64 looks promissing, and I'd me more than happy if I could > > > help with project. I already have done some initial testing and must > > > say crux for 64 bit processors is in demand. If I may suggest an idea > > > to add variable to pkgmk.conf like ie. ARCH_HOST=64, which would make > > > easier "architecture type" extraction. > > > > > > > > > Why would that be a good idea? > Because we could use one ports tree instead of two, which would be > easier to maintain. It might also result in horribly messy Pkgfiles. Also, footprints might differ among architectures, you might need different patches etc. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From wszystkie.fajne.loginy.zajete at gmail.com Sun Jun 22 12:50:38 2008 From: wszystkie.fajne.loginy.zajete at gmail.com (Bartlomiej Palmowski) Date: Sun, 22 Jun 2008 14:50:38 +0200 Subject: [crux64] crux64 Digest, Vol 7, Issue 1 Message-ID: <75f621b70806220550m680478eeg4f446407417d39ac@mail.gmail.com> > > > > > > Hi > > > > > > > > crux64 looks promissing, and I'd me more than happy if I could > > > > help with project. I already have done some initial testing and must > > > > say crux for 64 bit processors is in demand. If I may suggest an idea > > > > to add variable to pkgmk.conf like ie. ARCH_HOST=64, which would make > > > > easier "architecture type" extraction. > > > > > > > > > > > > > Why would that be a good idea? > > Because we could use one ports tree instead of two, which would be > > easier to maintain. > > It might also result in horribly messy Pkgfiles. Also, footprints might > differ among architectures, you might need different patches etc. > > Regards, > Tilman But on the other hand a lot of the x86_64 Pkgfiles are going to be duplicates of their i686 counterparts (I'd say most of them). regards Bartek From jw at smts.ch Sun Jun 22 13:55:34 2008 From: jw at smts.ch (Johannes Winkelmann) Date: Sun, 22 Jun 2008 15:55:34 +0200 Subject: [crux64] crux64 Digest, Vol 7, Issue 1 In-Reply-To: <485D2479.5050207@gmail.com> References: <485D2479.5050207@gmail.com> Message-ID: <20080622135534.GA9374@selenium.smts.lan> Hi, On Sat, Jun 21, 2008 at 17:55:37 +0200, Bartek Palmowski wrote: > > > > Hi > > > > > > crux64 looks promissing, and I'd me more than happy if I could > > > help with project. I already have done some initial testing and must > > > say crux for 64 bit processors is in demand. If I may suggest an idea > > > to add variable to pkgmk.conf like ie. ARCH_HOST=64, which would make > > > easier "architecture type" extraction. > > > > > > > > > Why would that be a good idea? > Because we could use one ports tree instead of two, which would be > easier to maintain. Having a single tree would mean that if the x86 maintainer would update a port, it would also be synced to all the other architectures without any testing. Also, it would not be possible to have separate versions of the same port, which can be needed if version X doesn't build/work on some arch. In addition, some ports are platform specific (e.g. lilo (x86), silo (sparc) etc.), and it wouldn't make sense to sync them to the user. Another big drawback of any "single tree" approach is that you need commit access to that tree. A separated approach means that anyone can start with a new architecture, without being dependent on others. Finally, I don't really buy the "easier to maintain" argument. The hard part is to get a port working. That's an initial effort. When you then do an update of that port, most time is spent on building and testing it, not bumping the version in Pkgfile. That's independent from whether there's a single tree, or separate ones. Hope this explains it, Regards Johannes -- Johannes Winkelmann mailto:jw at smts.ch Zurich, Switzerland http://jw.smts.ch From wszystkie.fajne.loginy.zajete at gmail.com Sun Jun 22 15:23:34 2008 From: wszystkie.fajne.loginy.zajete at gmail.com (Bartek Palmowski) Date: Sun, 22 Jun 2008 17:23:34 +0200 Subject: [crux64] crux64 Digest, Vol 7, Issue 1 Message-ID: <485E6E76.7080001@gmail.com> > > Having a single tree would mean that if the x86 maintainer would update > a port, it would also be synced to all the other architectures without > any testing. > Also, it would not be possible to have separate versions of the same > port, which can be needed if version X doesn't build/work on some arch. > > In addition, some ports are platform specific (e.g. lilo (x86), silo > (sparc) etc.), and it wouldn't make sense to sync them to the user. > > Another big drawback of any "single tree" approach is that you need > commit access to that tree. A separated approach means that anyone can > start with a new architecture, without being dependent on others. > > > Finally, I don't really buy the "easier to maintain" argument. The hard > part is to get a port working. That's an initial effort. When you then > do an update of that port, most time is spent on building and testing > it, not bumping the version in Pkgfile. That's independent from whether > there's a single tree, or separate ones. > > Hope this explains it, > Regards Johannes > But still "ARCH" variable could help with maintaining private repos, sometimes easy fix is needed for certain port to build, so contributing user instead of starting new repo could simply do the fix in one Pkgfile. regards Bartek From lucas at die.net.au Wed Jun 25 01:09:31 2008 From: lucas at die.net.au (Lucas Hazel) Date: Wed, 25 Jun 2008 11:09:31 +1000 Subject: [crux64] multilib vs. soft dependencies Message-ID: <20080625110931.3ffde349@akira.digitilocal> Some configure scripts automatically detect the presence of libraries, on a single library system this isn't a problem. However, when building 32bit support libraries on a mixed 32/64bit system the 64bit libraries get detected, but not tested by the configure script, only to fail during the linking process. It is not feasible to add all soft deps to the compat32 Pkgfile so these need to be detected. Rather than let these fail and let the user figure it out, I've come up with a solution, but I'm not sure how it would bode with with CRUX philosophy. I have a small script called compat32_dep_check(attached) which checks for the existence of soft dependencies. For example: # Description: CUPS - Common UNIX Printing System # URL: http://www.cups.org # Maintainer: J?rgen Daubert, juergen dot daubert at t-online dot de # Arch Maintainer: Lucas Hazel, lucas at die dot net dot au # Depends on: cups, libpng-compat32, libtiff-compat32, openssl-compat32 name=cups-compat32 version=1.3.7 release=1 source=(http://ftp.easysw.com/pub/cups/$version/cups-$version-source.tar.bz2 cups-config.patch cups-config32) compat32_dep_check $name dbus || exit 1 build () { .... I put it before build so the port will fail before we start extracting sources and save some time, which some of you might not notice, but I'm using NFS shared sources over a wireless link and source extraction can be quite slow at times. As I said, I'm not sure if this sits will with the CRUX way of doing things, such as enforcing dependencies. But it's a necessary evil to get compat32 ports to compile cleanly. That or we can let the end user figure out the soft deps on their own. I'm not sure how interested the rest of you are in multilib, but I'm not really interested in using a 64bit only system on my home desktop. I need to watch youtube videos and I need to be able to play GTA when the world is getting me down :) -- Lucas Hazel -------------- next part -------------- A non-text attachment was scrubbed... Name: compat32_dep_check.sh Type: application/x-shellscript Size: 447 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jw at smts.ch Wed Jun 25 06:15:20 2008 From: jw at smts.ch (Johannes Winkelmann) Date: Wed, 25 Jun 2008 08:15:20 +0200 Subject: [crux64] multilib vs. soft dependencies In-Reply-To: <20080625110931.3ffde349@akira.digitilocal> References: <20080625110931.3ffde349@akira.digitilocal> Message-ID: <20080625061520.GA9034@selenium.smts.lan> Hi Lucas, On Wed, Jun 25, 2008 at 11:09:31 +1000, Lucas Hazel wrote: > > Some configure scripts automatically detect the presence of libraries, > on a single library system this isn't a problem. However, when building > 32bit support libraries on a mixed 32/64bit system the 64bit libraries > get detected, but not tested by the configure script, only to fail > during the linking process. Interesting problem. From your script it seems that if the compat port of that soft dependency is installed, it will work again, did I read that correctly? Would it be a pkg-config problem then, or how is the wrong library detected by configure? I'd like to look at one of these to get a better idea, is cups a good example? > It is not feasible to add all soft deps to the compat32 Pkgfile so > these need to be detected. Rather than let these fail and let the user > figure it out, I've come up with a solution, but I'm not sure how it > would bode with with CRUX philosophy. Would it also be possible to disable the soft dependencies explicitely? I think you mentioned something like this for libxslt. Or the other way around, adding the compat32 ports as hard dependencies. Both are just workarounds, though, but depending on the number of ports we'll end up with in compat32 could also be feasible. > As I said, I'm not sure if this sits will with the CRUX way of doing > things, such as enforcing dependencies. But it's a necessary evil to > get compat32 ports to compile cleanly. That or we can let the end user > figure out the soft deps on their own. One thing I'm not sure yet is how many compat port we will end up in the long run, i.e. whether it's okay to cover to typical use cases, or whether we need more and more over time since users want more ports. If the compat ports are an small set, then I think it could be okay to add a special solution, especially since I still hope that at some point in time we'll be able to drop the compat ports altogether, although that may take some years... I'll have to think a bit longer about the way you implemented it (lack of coffee and such). The one thing I'd like to avoid is that the method as is is picked up by other packagers to run random scripts in Pkgfiles, because they see it in our ports (you know, like running pre-install from there). > I'm not sure how interested the rest of you are in multilib, but I'm > not really interested in using a 64bit only system on my home desktop. > I need to watch youtube videos and I need to be able to play GTA when > the world is getting me down :) Heh. I'm pretty sure that the majority of our users today will have some 32-bit applications they want to run, so at this point multilib seems favourable to me. As mentioned I hope that we can go pure 64 at some point in time, but I don't see that happening anytime soon. Thanks, Johannes -- Johannes Winkelmann mailto:jw at smts.ch Zurich, Switzerland http://jw.smts.ch From mike at openbunker.org Wed Jun 25 10:30:13 2008 From: mike at openbunker.org (Mikhail Kolesnik) Date: Wed, 25 Jun 2008 13:30:13 +0300 Subject: [crux64] multilib vs. soft dependencies In-Reply-To: <20080625061520.GA9034@selenium.smts.lan> References: <20080625110931.3ffde349@akira.digitilocal> <20080625061520.GA9034@selenium.smts.lan> Message-ID: <20080625133013.1c1110e3@amilo.home> Hello, Johannes. On Wed, 25 Jun 2008 08:15:20 +0200 Johannes Winkelmann wrote: > > I'm not sure how interested the rest of you are in multilib, but I'm > > not really interested in using a 64bit only system on my home desktop. > > I need to watch youtube videos and I need to be able to play GTA when > > the world is getting me down :) > Heh. I'm pretty sure that the majority of our users today will have some > 32-bit applications they want to run, so at this point multilib seems > favourable to me. As mentioned I hope that we can go pure 64 at some > point in time, but I don't see that happening anytime soon. Multilib system solves just a few things forcing to deal with many (still undefined) hooks and 'special cases'. As the time goes, those (32bit) binary-only apps might be replaced by major vendors. I thought it could be possible to start from 'pure 64bit' set of core/opt ports and make a test release. The next step could be to clone that set and convert it to a multilib system, if the demand will still be high. The point here is: desktop user will have almost no benefits any 64bit system, but multilib version of that will give him some pain (time to solve issues, maintain multilib ports). On the other hand, server 'pure 64bit' system will be much more simple and might have some real speed and scaling improvements. I know, creating 'pure 64bit' system is not that hard (even for a single person), but I really want some kind of official crux release for that. It makes much easier to cooperate and find bugs with fairly wide community. -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta From lucas at die.net.au Wed Jun 25 13:18:26 2008 From: lucas at die.net.au (Lucas Hazel) Date: Wed, 25 Jun 2008 23:18:26 +1000 Subject: [crux64] multilib vs. soft dependencies In-Reply-To: <20080625061520.GA9034@selenium.smts.lan> References: <20080625110931.3ffde349@akira.digitilocal> <20080625061520.GA9034@selenium.smts.lan> Message-ID: <20080625231826.7fcde840@akira.digitilocal> On Wed, 25 Jun 2008 08:15:20 +0200 Johannes Winkelmann wrote: > Hi Lucas, > > On Wed, Jun 25, 2008 at 11:09:31 +1000, Lucas Hazel wrote: > > > > Some configure scripts automatically detect the presence of > > libraries, on a single library system this isn't a problem. > > However, when building 32bit support libraries on a mixed 32/64bit > > system the 64bit libraries get detected, but not tested by the > > configure script, only to fail during the linking process. > Interesting problem. From your script it seems that if the compat port > of that soft dependency is installed, it will work again, did I read > that correctly? That's correct. You either remove the 64bit port, build it, reinstall the 64bit port or install the compat32 port and build again. > Would it be a pkg-config problem then, or how is the wrong library > detected by configure? If only everyone used pkg-config, things would be a lot easier. In pkgmk.conf I just set PKG_CONFIG and PKGCONFIG (make up your mind dammit!) to /usr/bin/pkg-config32, which solves a lot of the auto detection problems (pkg-config --exists). However there are still a collection of ports that ship with their own *-config script. This is where the problems exist. Initially *_CONFIG=/usr/bin/*-config needs to be set in pkgmk.conf (a pkgmk.conf.d would be nice ;) ), however I found that some will fall back to just detecting the presence of headers and the problem is back again. That said, I've only come across 2 ports that need the compat32_dep_check hack (but there may be a better solution), gtk-compat32 and libxslt-compat32. > I'd like to look at one of these to get a better idea, is cups a good > example? I have the ports available on http://git.die.net.au/cgit compat32 and multilib ports are available for core, opt and xorg. I'd like to see how mine are different from the pure64 alternative, as I suspect that other than a few core ports, not much will be different. If you want to clone core for example it's git://git.die.net.au/crux/ports/core > > It is not feasible to add all soft deps to the compat32 Pkgfile so > > these need to be detected. Rather than let these fail and let the > > user figure it out, I've come up with a solution, but I'm not sure > > how it would bode with with CRUX philosophy. > Would it also be possible to disable the soft dependencies > explicitely? I think you mentioned something like this for libxslt. > Or the other way around, adding the compat32 ports as hard > dependencies. > > Both are just workarounds, though, but depending on the number of > ports we'll end up with in compat32 could also be feasible. > > > > As I said, I'm not sure if this sits will with the CRUX way of doing > > things, such as enforcing dependencies. But it's a necessary evil to > > get compat32 ports to compile cleanly. That or we can let the end > > user figure out the soft deps on their own. > One thing I'm not sure yet is how many compat port we will end up in > the long run, i.e. whether it's okay to cover to typical use cases, or > whether we need more and more over time since users want more ports. I'm up to 64 compat32 ports, which was about how many I had before I started the new repos. The bulk of this is xorg and gtk stuff, which should be enough get get a lot of popular 32bit binary programs to work (flash, acroread, wine). There may be a few more compat32 ports needed, but I belived most of the groundwork has been laid here. > If the compat ports are an small set, then I think it could be okay to > add a special solution, especially since I still hope that at some > point in time we'll be able to drop the compat ports altogether, > although that may take some years... I'll have to think a bit longer > about the way you implemented it (lack of coffee and such). There's probably a better solution, but as the saying goes, a bad solution is better than no solution at all. If the number of cases that have soft deps turns out to be quite small it would be quite feasible to simply write it into the Pkgfile for each case. > The one thing I'd like to avoid is that the method as is is picked up > by other packagers to run random scripts in Pkgfiles, because they > see it in our ports (you know, like running pre-install from there). ^^ I just wrote the drop in script because I had a fear that I would end up writing the same few lines over and over, which in the end turned out to be for only 2 cases. Hopefully there'll be a way to get around it, but for now it's working. > > I'm not sure how interested the rest of you are in multilib, but I'm > > not really interested in using a 64bit only system on my home > > desktop. I need to watch youtube videos and I need to be able to > > play GTA when the world is getting me down :) > Heh. I'm pretty sure that the majority of our users today will have > some 32-bit applications they want to run, so at this point multilib > seems favourable to me. As mentioned I hope that we can go pure 64 at > some point in time, but I don't see that happening anytime soon. Well, I for one will be sticking with multilib regardless of which way the official version decides to go. Granted many mainstream programs will go 64bit in the end (I hear that flash10 will have 64bit linux support), redhad is working on an opensource java plugin, etc), unfortunately I don't think 32bit is going anyware for a long time. -- Lucas Hazel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jw at smts.ch Thu Jun 26 08:25:33 2008 From: jw at smts.ch (Johannes Winkelmann) Date: Thu, 26 Jun 2008 10:25:33 +0200 Subject: [crux64] multilib vs. pure 64 Message-ID: <20080626082533.GA13500@selenium.smts.lan> Hi there, I'll start a separate thread to avoid polluting the "soft-dep" thread. A number of people seem to have rather strong feelings against multilib, however i get the impression that the impact is in fact not that big. To help us with deciding, here's a summary of what I think would be a good approach: 1. core-x86_64/{glibc,gcc,binutils,bin86} multilib 2. all the rest of core-x86_64 and opt-x86_64 is pure 64-bit 3. we offer separate compat32 repositories (as compat32.rsync.inactive), For the pure 64 user, the only drawback is the additional 32-bit binaries for glibc, gcc and binutils. At the same time, the user has the option to add the 32-bit compatibility layer should the need arise later on, without the need to replace glibc/gcc on the running system. - there's no performance penalty - there's no additional issues (since compat32 is purely optional) which can happen on such a system that wouldn't on a absolutely pure64 one - there are no workarounds/hack required in Pkgfiles, pkgutils or pkgmk.conf For us developers, it means that with a single platform, we can cover both groups of use(r)s. Those that care about compat32 can join as maintainer in these repos as well, - there's no additional work involved, we have to maintain gcc et al anyway, and helping in compat32 is optional So to me, it boils down to this: - some disk space "wasted" when running only 64-bit binaries + chance to add the compat32 layer at any point without any hassle + single platform, which means all development efforts, bug solutions etc. help both the "pure" and "non-pure" users. Anything I missed? Thanks for reading, Johannes -- Johannes Winkelmann mailto:jw at smts.ch Zurich, Switzerland http://jw.smts.ch From jue at jue.li Thu Jun 26 09:12:36 2008 From: jue at jue.li (Juergen Daubert) Date: Thu, 26 Jun 2008 11:12:36 +0200 Subject: [crux64] multilib vs. pure 64 In-Reply-To: <20080626082533.GA13500@selenium.smts.lan> References: <20080626082533.GA13500@selenium.smts.lan> Message-ID: <20080626091236.GB3139@jue.netz> On Thu, Jun 26, 2008 at 10:25:33AM +0200, Johannes Winkelmann wrote: > Hi there, Hello, > I'll start a separate thread to avoid polluting the "soft-dep" thread. A > number of people seem to have rather strong feelings against multilib, > however i get the impression that the impact is in fact not that big. To > help us with deciding, here's a summary of what I think would be a good > approach: > > 1. core-x86_64/{glibc,gcc,binutils,bin86} multilib Sorry, I do not understand that glibc part. The 32-bit libs has to be build in a second run anyway IMO, so it should be possible to split them out? > Thanks for reading, Thanks for your fine summary. Greetings Juergen -- Juergen Daubert | mailto:jue at jue.li Korb, Germany | http://jue.li/crux From jw at smts.ch Fri Jun 27 08:59:26 2008 From: jw at smts.ch (Johannes Winkelmann) Date: Fri, 27 Jun 2008 10:59:26 +0200 Subject: [crux64] multilib vs. pure 64 In-Reply-To: <20080626091236.GB3139@jue.netz> References: <20080626082533.GA13500@selenium.smts.lan> <20080626091236.GB3139@jue.netz> Message-ID: <20080627085926.GA6919@selenium.smts.lan> Hi J?rgen, On Thu, Jun 26, 2008 at 11:12:36 +0200, Juergen Daubert wrote: > On Thu, Jun 26, 2008 at 10:25:33AM +0200, Johannes Winkelmann wrote: > > Hi there, > > Hello, > > > I'll start a separate thread to avoid polluting the "soft-dep" thread. A > > number of people seem to have rather strong feelings against multilib, > > however i get the impression that the impact is in fact not that big. To > > help us with deciding, here's a summary of what I think would be a good > > approach: > > > > 1. core-x86_64/{glibc,gcc,binutils,bin86} multilib > > Sorry, I do not understand that glibc part. The 32-bit libs has to be > build in a second run anyway IMO, so it should be possible to split > them out? Ah, I got that one wrong. So it would be in the compat32 layer too, right? So do I understand that correctly that it's mainly a question of whether we want a multilib toolchain by default? Thanks, Johannes -- Johannes Winkelmann mailto:jw at smts.ch Zurich, Switzerland http://jw.smts.ch From mvanroy at bellsouth.net Fri Jun 27 22:28:52 2008 From: mvanroy at bellsouth.net (Mike VanRoy) Date: Fri, 27 Jun 2008 18:28:52 -0400 Subject: [crux64] multilib vs. pure 64 In-Reply-To: <20080627085926.GA6919@selenium.smts.lan> References: <20080626082533.GA13500@selenium.smts.lan> <20080626091236.GB3139@jue.netz> <20080627085926.GA6919@selenium.smts.lan> Message-ID: <486569A4.40706@bellsouth.net> Greetings: FYI, I have been running a "pure 64" (no multilib) version of crux for a couple of years. Johannes Winkelmann wrote: > Hi J?rgen, > > On Thu, Jun 26, 2008 at 11:12:36 +0200, Juergen Daubert wrote: > >> On Thu, Jun 26, 2008 at 10:25:33AM +0200, Johannes Winkelmann wrote: >> >>> Hi there, >>> >> Hello, >> >> >>> I'll start a separate thread to avoid polluting the "soft-dep" thread. A >>> number of people seem to have rather strong feelings against multilib, >>> however i get the impression that the impact is in fact not that big. To >>> help us with deciding, here's a summary of what I think would be a good >>> approach: >>> >>> 1. core-x86_64/{glibc,gcc,binutils,bin86} multilib >>> With "pure 64" ,deviation from standard Crux is minimal and almost all the ports build with no (or minimal) patching. IMHO multilib is more trouble than it's worth. I do see some drawbacks, but most have alternatives: 1- I admit the lack of a good flash player is a pain, but gnash and swfdec are still in dev. 2 - xpdf is a good replacement for Acroread. > So do I understand that correctly that it's mainly a question of whether > we want a multilib toolchain by default? > > Thanks, Johannes > For what it's worth, my vote is no to multilib. If anyone is interested, I have a rudimentary patch for pkgmk and a patching system for standard (32 bit) ports that need changes. Thanks ... Mike