[Clc-crux64] New x86_64 iso available!

Johannes Winkelmann jw at tks6.net
Sat Apr 9 08:41:14 UTC 2005

Hi Jeremy,

On Fri, Apr 08, 2005 at 15:51:40 -0600, Jeremy Jones wrote:
> Hi all!
> finished up with my latest x86_64 crux iso! 

> i think it's pretty clean
> this time.  should work just like the vanilla crux installation --
> nothing special to do other than follow the normal crux install
> directions.  you can find the iso, as well as my base64.httpup,
> opt64.httpup, and a readme at:
> http://www.samnjack.com/crux-amd64
> (please be gentle with my bandwith!)
Both Per and Matt have mirror'red my sparc test images, I'm sure they'll
mirror yours if you ask them (if Per answers fast enough, you don't have
to bother Matt since he mirrors Per's ftp anyway ;-)).

> Other than that, everything ought to work just fine.
> If you find something terribly wrong, please inform me
> (you'll find my e-mail address below) or anyone else
> who decides to take this project on.  It may be worth
> the effort, assuming there's more than three or four
> people using this, to maintain repositories of contrib
> and unmaintained ports that require changes for x86_64,
> similar to what I've done with base and opt.  Time will
> tell.
We've discussed the introduction of subprojects at CLC, and this would
definitely be a good candidate. Unfortunately, this is one of those
"post 2.1" things.

> Once again, I think building into pkgutils and the ports
> system a true multi-arch capability would be wonderful.
> Maintainers of the ppc and sparc64 branches would probably
> agree...
Well, we had this discussion some time ago (and also at CRUXCon last
year). At first, I was in favour of a multiarch pkgutils too, but I
changed my mind. In my opinion, changes should not appear in a arch
specific tree unless tested and maintained, not because it's in the
$OTHERARCH tree. This implies having independently versioned trees. In
order to make that process as easy as possible, the revision control
system should support merging from the other branches.

I've written a very small wrapper around subversion to allow this in a
(to me) logical way:

To give you an impression what's needed, here a small excerpt how to
merge a port from x86 to x86_64:

First, the initial setup:
  #define from and to branches
  export XSVN_SRC_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86 
  export XSVN_BASE_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86_64
  export XSVN_RELEASE=CRUX-2_0

  # initial checkout
  mkdir ~/ports-x86_64
  cd ~/ports-x86_64 
  svn co $XSVN_BASE_REPO/trunk
  cd trunk

Now for the real fun part, the merge
  xsvn merge-from htop # <- merges port from x86 to working copy
  ## build port, check whether it works on x86_64, then either 'svn
  ## revert' or
  svn ci -m "commit htop to x86_64"

finally, to "tag" it for a specific release of CRUX:
  xsvn release opt htop # add htop to x86_64, collection 'opt'

Of course, this would mean that for every port on $ARCH, someone has to
maintain  it (even though maintainance in this case might just be a
matter of checking for updates in another tree, and merging and testing
those changes). CRUX PPC does it differently, they let their users use the
x86 ports (at least last this discussion was help), which is unfortunate
in my eyes. As for CRUX/SPARC, I don't plan to include ports which are
not tested on that specific platform.

I'm more than happy to provide  write access to the berlios
subversion tree for persons willing to test this. Unfortunately, I'm not
sync'ing Per's cvs repo with subversion yet, but the script is almost
This would then hourly sync the x86 Subversion branch with Per's CVSUp,
and allow us to maintain the other trees against it.

There's another nice side effect of this: svn can be used as backend for
ports(8), allowing for an efficient way to update ports since only
deltas are transferred; furthermore, it's quite portable and builds just
fine on sparc's, so I don't expect big problems on x86_64 either.
Finally, subversion can be told to use http as transport (not at berlios
unfortunately), which would solve the "behind proxy" issue of cvsup.

Okay, I'm sorry this got so long, but it's one of my main projects right
now since I'm planning to start maintaining a CRUX/SPARC tree in a
serious way, and this is the path we've chosen. As always, feedback is
highly appreciated.

Kind regards and thanks for reading, 
Johannes Winkelmann              mailto:jw at tks6.net
Bern, Switzerland                http://jw.tks6.net

More information about the crux64 mailing list