In the upcoming CRUX64 release, I am dabbling in a multiarch implementation. This is a deviation from the method used in 2.1.1-rc2 that uses a seperate compat32 repo. The implemenation I am using extends existing ports using the following hierarchy (? indicates that the file is optional) port/ Pkgfile .footprint .md5sum x86_64/ Pkgfile? .footprint? ... (x86_64 specific sources included in port) compat32/ Pkgfile? ... The build variables can be overwritten in the required arch's Pkgfile, thus making it only necesarry to change the build script for many ports. I have chosen this method mainly to make it easier to follow the official crux release cycle via git, to remove the need for constant conflict resolution (if there is an easier way, let me know as I am fairly new to git). I have also added multiarch support to pkgmk, you can specify the arch with -a <arch>, for example to build the compat32 glib port: cd /usr/port/opt; pkgmk -a compat32 This will build a package named glib-compat32#... This all works really well in terms of development, as I tend to build the dependency chain manually rather than by using prt-get. However, this method breaks prt-get in many ways (due to it not being aware of the multiarch ports structure) The way I see it there are 2 options: 1. Continue using the multiarch structure, modifying existing utilities as needed. 2. Only use the multiarch in the development tree and use a utility to merge each arch into it's own public repo. Each has their own pros and cons, however I feel that the true multiarch support is something CRUX needs to continue to thrive. We currently have derivative, CRUX projects for i586, ulibc, ppc, sparc, arm, x86_64 and even openbsd some sort of unification is needed. Personally, I get the impression that multiarch is an issue the offical CRUX developers are not taking seriously. Johannes was probably the only one taking it seriously (mainly because he started the sparc port), but he's quit the development team. Also, irc://irc.freenode.net#crux64 See you there....maybe. -- Lucas Hazel <lucas@die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================
Lucas Hazel wrote:
In the upcoming CRUX64 release, I am dabbling in a multiarch implementation. This is a deviation from the method used in 2.1.1-rc2 that uses a seperate compat32 repo.
I am using the original 2.2-test1 and gradually going to 2.3 ports. Only I am going strictly x86_64.
The implemenation I am using extends existing ports using the following hierarchy (? indicates that the file is optional)
port/ Pkgfile .footprint .md5sum
x86_64/ Pkgfile? .footprint? ... (x86_64 specific sources included in port)
compat32/ Pkgfile? ...
IMHO this makes things too complicated. Every port has to be modified. I prefer to disable multiarch and eliminate the lib32 altogether. So far it seems to work in all but a few core and opt ports without modification.
I have also added multiarch support to pkgmk, you can specify the arch with -a <arch>, for example to build the compat32 glib port:
cd /usr/port/opt; pkgmk -a compat32
This will build a package named glib-compat32#...
mThis all works really well in terms of development, as I tend to build the dependency chain manually rather than by using prt-get.
However, this method breaks prt-get in many ways (due to it not being aware of the multiarch ports structure)
The way I see it there are 2 options:
1. Continue using the multiarch structure, modifying existing utilities as needed.
2. Only use the multiarch in the development tree and use a utility to merge each arch into it's own public repo.
It would be nice to see crux-devel do that implementation (#2) for crux.
irc://irc.freenode.net#crux64
See you there....maybe.
OK - see ya - Mike aka jmvr
On Thu, 11 Jan 2007 12:49:02 -0500 mvanroy <mvanroy@bellsouth.net> wrote:
Lucas Hazel wrote:
In the upcoming CRUX64 release, I am dabbling in a multiarch implementation. This is a deviation from the method used in 2.1.1-rc2 that uses a seperate compat32 repo.
I am using the original 2.2-test1 and gradually going to 2.3 ports. Only I am going strictly x86_64.
The implemenation I am using extends existing ports using the following hierarchy (? indicates that the file is optional)
port/ Pkgfile .footprint .md5sum
x86_64/ Pkgfile? .footprint? ... (x86_64 specific sources included in port)
compat32/ Pkgfile? ...
IMHO this makes things too complicated. Every port has to be modified. I prefer to disable multiarch and eliminate the lib32 altogether. So far it seems to work in all but a few core and opt ports without modification.
No, not every port needs to be modified, only the ones that require modification. Also you are confusing multiarch with multilib. 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. -- Lucas Hazel <lucas@die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================
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
participants (2)
-
Lucas Hazel -
mvanroy