Lucas Hazel wrote:
No, not every port needs to be modified, only the ones that require modification. Also you are confusing multiarch with multilib.
Not exactly, but for the end user, one kind of precludes the other.
I should also point out, that in the modifications I have made to the pkgmk script, a port will attempt to use it's arch subdirectory, but will default to the base port. Also, that if the target arch is the same at the host arch the $name-$arch#... naming scheme is not used, rather it reverts to the usually $name#... package name.
I suppose in such a ports tree there should be a better method to define a difference between multilib and pure64 (this would essenstially just be a naming mechanism). However the main intention of the multiarch port structure was to also allow other architectures to be integrated into the structure, not just x86_64/compat32, so that all developers of CRUX could work together rather than in the splintered environment that currently exists.
I have spoken to some of the CRUXPPC developers, they are interested in the idea and there may be the possibility I will be merging my ports tree with theirs into such a multiarch system.
This sounds great. The hard part would be to convince the "mainliners" , which would actually be the way to go. Otherwise merging into CRUXPPC would be good.When crux64 died (or at least fainted), I was looking at T2, which applies the same approach, but I liked CRUX and preferred to stay on as long as possible. I also modified my pkgmk, but if you could send me a patch, i would be glad check out your method and hopefully get on the same track. BTW, due to time constraints, I consider myself an end user rather than a developer, but it's seems more and more involvement is necessary to keep the 64 thing going. LOL - Mike