Date: Fri, 27 Jun 2014 08:35:52 +0200 From: John Hay <jhay@meraka.org.za> To: Baptiste Daroussin <bapt@freebsd.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: [Patch] Using MACHINE_ARCH identifiers in pkg Message-ID: <20140627063552.GB65987@zibbi.meraka.csir.co.za> In-Reply-To: <20140626213045.GF24440@ivaldir.etoilebsd.net> References: <5383EEB6.6010703@freebsd.org> <538614AB.4070803@freebsd.org> <20140528170440.GA80273@ivaldir.etoilebsd.net> <53A31C56.90401@freebsd.org> <20140626213045.GF24440@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 26, 2014 at 11:30:45PM +0200, Baptiste Daroussin wrote: > On Thu, Jun 19, 2014 at 10:22:30AM -0700, Nathan Whitehorn wrote: > > > > > > On 05/28/14 10:04, Baptiste Daroussin wrote: > > > On Wed, May 28, 2014 at 09:54:03AM -0700, Nathan Whitehorn wrote: > > >> 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 > > >> > > >> > > >> > > > Thanks I'll be away for a couple of days, but I'll have a look and test your > > > patch in all situation we need to support and come back to you if needed or > > > directly commit; > > > > > > regards, > > > Bapt > > > > Have you had a chance to look at this yet? I'm happy to help with any > > testing if you need. > > -Nathan > > I do like the appraoch but I haven't yet had time to study the side effect, it > is already complicated to get pkg 1.3 out, I are quite close now so this will > wait for 1.4, but I'll push it on top of my TODO list for 1.4. Will 1.3 work for armeb platforms like the AVILA and CAMBRIA? At the moment I took a small crowbar to libpkg/pkg_elf.c to just replace the check and failure with "failed to find the version elf note" with: char localname[] = "freebsd"; osname = localname; version = 11 * 100000; That give me an architecture according to pkg of: root@cambria-build:~ # pkg info pkg | grep ^Arch Architecture : freebsd:11:arm:32:eb:eabi:softfp If one wants to work it out from a file, one can probably look at how file does it: root@cambria-build:~ # file /bin/sh /bin/sh: ELF 32-bit MSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), FreeBSD-style, for FreeBSD 11.0 (1100023), stripped Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140627063552.GB65987>