Hi, On Sat, Aug 06, 2005 at 20:34:12 +0200, Daniel Mueller wrote:
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 [...] I guess I wasn't too clear, but the context for this statement is really important. I think it would be important that CRUX/x86 feels the same as CRUX/SPARC; using a system of one single primary maintainer would imply this anyway.
Also, there will always be differences between core ports for the architectures, but those ports will probably have primary maintainers on all platforms. I'll add this as a note to this section.
=> CRUX64 behaves differently than CRUX (i686) especially files in /dev. That's pretty much logical, considering that you want to support current kernels :-). That's really just an issue of timing; if CRUX 2.2 was to be released anytime soon, it would most certainly use udev as well, since - as you mention - devfsd has been thrown out of the configuration.
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.). If we make it easy enough for architecture maintainers to keep track of changes, we can hopefully keep large parts of the trees.
/usr/ports/ base-i686 base-x86_64 base-ppc
(looks ugly..) Yeah, here as well it should look the same on every architecture; arch specifics should only affect developers, not users.
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). Well, some tools would certainly help to keep track of ports. I'd expect architecture maintainers to have a large number of ports, so some kind of tracking will certainly be needed. Whether you want to enjoy automated merging or not is certainly up to every maintainer. I know I would us it for certain updates (note that this is just for merging changes to your tree; you can still do a 'cvs diff' then to see what happend, and throw away those changes again (assuming your primary tree is in CVS)).
okay, that's all so far. Hope you were able to fight through my DEnglish :) Obviously, I was ;-). Thanks for the comments.
Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net