![](https://secure.gravatar.com/avatar/3b96b0c16d52a4756be8a3da4c2789a3.jpg?s=120&d=mm&r=g)
Hello, Johannes, here is _my_ point of view. At the moment there are two different CRUX-x86_64 versions out: - Jeremy's CRUX-x86-64 which is (very) close to Per's CRUX i686, and - Daniel's CRUX64, which has experienced some heavy changes. I consider my CRUX64 as a fork of Per's CRUX. I'll give you an examples and the reason why I have made the change.
- arch maintainers are not supposed to change features, e.g. enable the gui in mplayer. OTOH the primary maintainer will have to make sure that his port suits the needs of the CRUX community (arch independent)
I have replaced devfs against Matt's hotplug/udev ports. If you download the newest kernel 2.6.13-rc5 you'll see that devfs is no longer available - they (Greg Kroah-Hartman?) removed the corresponding menu entries so that you cannot choose it during the kernel configuration. I personally think it was a mistake to ship CRUX 2.1 with devfs{d} again (Per knows about my opinion). Therefore CRUX64 comes with some more ports in its base collection. => CRUX64 behaves differently than CRUX (i686) especially files in /dev. Since the AMD64/EM64T technology offers both, 64bit and 32bit operation modes we need to separate those libraries from each other. In the majority of cases the configure scripts get some additional options but sometimes there are also patches needed.
Then there's the gentoo approach, using if clauses to enable/disable packaging instructions specifically per architectures
After deeply thinking about I agree with you. Different Pkgfiles / .footprint / .md5sums/.. for each architecture are the best (and only?) way to keep CRUX's main goal: "keep it simple". I would separate each arch in its own trunk and only merge if possible. For sure, that will result in a decreased number of ports (the price for K.I.S.S.). /usr/ports/ base-i686 base-x86_64 base-ppc (looks ugly..)
There have also been complaints from PPC users to x86 maintainers about their ports not building in the past, simply because the "maintainer" field obviously listed the x86 maintainer.
*cough* sometimes I also left the 'Maintainer' flag as it is. I don't want to earn all the credit for things I've not fully done myself...
4. A smart tool is used to get ports from other architectures, and merge them
Mhhh, I don't think there is a need for such a tool or is there? A tool which informs me (as AM [architecture maintainer :-]) about a newer/modified port in ARCH xyz would be nice. .oO(mppa?) I like to manually do the necessary port adjustments (note: by hand). okay, that's all so far. Hope you were able to fight through my DEnglish :) bye, danm -- Daniel Mueller http://www.danm.de Berlin, Germany OpenPGP: 1024D/E4F4383A