From owner-freebsd-ports@FreeBSD.ORG Wed May 28 16:54:06 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 097F2441; Wed, 28 May 2014 16:54:06 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8462BF1; Wed, 28 May 2014 16:54:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 3DFEB38056; Wed, 28 May 2014 11:54:05 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id YkF73TjmoEG3; Wed, 28 May 2014 11:54:05 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id B9ABA38046; Wed, 28 May 2014 11:54:04 -0500 (CDT) Message-ID: <538614AB.4070803@freebsd.org> Date: Wed, 28 May 2014 09:54:03 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: FreeBSD Mailing List Subject: [Patch] Using MACHINE_ARCH identifiers in pkg References: <5383EEB6.6010703@freebsd.org> In-Reply-To: <5383EEB6.6010703@freebsd.org> X-Forwarded-Message-Id: <5383EEB6.6010703@freebsd.org> Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit Cc: Baptiste Daroussin , Warner Losh X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:54:06 -0000 The following was in a deep and increasingly branched thread on the SVN list. I've forwarded the relevant part here. The discussion was on using MACHINE_ARCH codes for package architectures in pkg instead of the existing ones (which are equivalent) to make script-writing easier and improve consistency with the way the src and ports trees work. The patches below are designed to make transitioning the architecture identifiers as painless as possible. -Nathan ------------------------------------------------------------------------ I've written two patches today. The first (http://people.freebsd.org/~nwhitehorn/pkg_machinearch.diff) is to pkg itself and the second (http://people.freebsd.org/~nwhitehorn/pkg_bootstrap_machinearch.diff) is to the pkg bootstrapper in base. These switch pkg from using identifiers like "freebsd:11:arm:32:eb:eabi:softfp" to identifiers like "FreeBSD:11:armeb", matching the canonical FreeBSD platform identifiers. The strings it uses can be predicted easily from scripts, as they are identical in all cases to the output of `uname -s`:`uname -r | cut -f 1 -d .`:`uname -p`. I tried to avoid changing much, so the patches are pretty short. Internally, the patch introduces a translation table to pkg that contains all extant FreeBSD and Dragonfly BSD architectures and moves between the ELF-based coding and MACHINE_ARCH values. This is kind of gross, but has the least possibility for regression, and can easily be changed behind the scenes later. Platform detection uses the same ELF-parsing code as before. The current/previous values are also kept so that the patched pkg can install a package marked either with an x86:64 or amd64-type architecture ID (symlinks will be needed for a little bit on the package server to allow both clients to work). Limited testing suggests it works well -- I can fetch and install packages fine. More testing would be great. One small issue is how to bootstrap the change for existing binary package users. The modified pkg can use packages with either architecture ID just fine, but the current one will barf on the FreeBSD:11:amd64 package containing its own update. There are a couple of options: manual instructions, marking that one package with the old-style architecture ID, etc. None should be more than slightly irritating, though. The least bumpy route, I think, is making directories with both the old and new names, but putting only one package in the old-named directory: a special intermediate version of pkg marked with the old architecture ID but able to install from the new one. Then you just have to deal with two rounds of updates without any other intervention, which is not so bad. -Nathan