- crux64 - lists.crux.nu

multilib vs. pure 64
by Johannes Winkelmann 27 Jun '08

27 Jun '08

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@smts.ch Zurich, Switzerland http://jw.smts.ch

3 3

multilib vs. soft dependencies
by Lucas Hazel 25 Jun '08

25 Jun '08

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 <lucas(a)die.net.au>

3 3

crux64 Digest, Vol 7, Issue 1
by Bartek Palmowski 22 Jun '08

22 Jun '08

> > 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

1 0

Re: [crux64] crux64 Digest, Vol 7, Issue 1
by Bartek Palmowski 22 Jun '08

22 Jun '08

> > 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

3 2

Re: [crux64] crux64 Digest, Vol 7, Issue 1
by Bartlomiej Palmowski 22 Jun '08

22 Jun '08

> > > > > > 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

1 0

Re: [crux64] [crux-devel] 64-bit test run
by Tilman Sauerbeck 21 Jun '08

21 Jun '08

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?

1 0

core ports package
by Lucas Hazel 24 Feb '07

24 Feb '07

To prevent a massive bugfest when CRUX64-2.3 get's released I'll start making work available online. I currently have core and xorg going and a small selection from opt. The core ports are now available online: http://nipul.die.net.au/core.tgz Once I decide where to store the repositories, I will update the ports port. This also includes a multiarch version of pkgutils, so consider it very beta. Regarding multiarch pkgutils. To reference non-native ports (ie compat32) I have chosen the following syntax name@arch, you can see this in the x86_64 version of gcc which required glibc@compat32. To specify to build a compat32 port simply use pkgmk -a compat32. However keep in mind that this breaks prt-get. The first time around, pkgutils will have to be built manually. Once that is done pkgutils can be rebuilt and installed using package management. It is recommended current users of Daniel's version of CRUX64 do a fresh install due to the restructuring of core and the reversal of the lib64->lib symlinks. However that said, I have successfully migrated from the old version to this one by hand, YMMV. -- Lucas Hazel <lucas(a)die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================

1 0

Status Report
by Lucas Hazel 13 Feb '07

13 Feb '07

I've been asked about the status of CRUX64 as I have been quiet about it. I can assure everyone that I have not abandoned the project. I'll now attempt to give a rundown of things as they stand. As things have changed quite a bit from Daniel's release. Ports: Daniel introduced many new features not seen in CRUX/Linux, notably PAM. I have removed all of this in favour of following the official ports as closely as possible, only including extra ports necessary to the distribution (ie: linux32). To reduce the amount of maintenance required, the ports will also be identical to the official ports tree in terms of features, versions, patches, etc (again only making changes required for the x86_64 architecture). File System Hierarchy: To reduce the need modifying ports, lib and lib64 will be reversed. That is, lib64 will be symlinked to lib. This seems to be the popular choice among other 64 bit distributions and reduced the need for modifying ports for x86_64. Preferably pkgutils should handle symlinks correctly. A conversation with one of the CRUX mods (I forget who) revealed that pkgutils will not be receiving any major updates for the 2.3 release (INSTALL, symlinks, etc). Multiarch: I have discussed this previously in more detail (refer to archives). The main issue with the implementation is that many utilities will need to be modified to be made multiarch aware. Until such a date when there is an official multiarch solution there will be 2 sets of ports, the development branch and the release branch. The development branch will be in the multiarch format, while the release branch will be processed from development to fit the traditional port hierarchy. Release Schedule: There is not release schedule as yet, as this version of CRUX64 will be released as 2.3, I would like to wait for the official 2.3 release. I'm lazy and figure I'll just wait until the new dependency tree is finalised (re: xorg) rather than do it myself. Secondly we are expecting a child any day now (due on Sunday) so things are a bit hectic here at the moment. So the only times I get to work on CRUX64 are when everyone is asleep or on a really slow day at work. So bear with me for now, it will be ready when it's ready :) -- Lucas Hazel <lucas(a)die.net.au>

1 0

progress
by Tomas Lindquist Olsen 29 Jan '07

29 Jan '07

Hi folks. I'm currently in a position where I'm about to destroy my Windows installation and go back to good old Linux. Has there been any progress on the new Crux64 ? I would very much like to get this instead of Gentoo or something. I'd really like to run a 64 bit version so the old crux32 is not really an option. I'm not that much of a hacker when it comes to making distros, but I know C/C++/D very well and am interested in helping out if I can. Also I did quite a lot of "porting" 32 bit ports to 64 bit last time, so here I could probably help out. Hoping to hear some good news. -Tomas

2 2

multiarch
by Lucas Hazel 12 Jan '07

12 Jan '07

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(a)die.net.au> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================

2 3