Hey Baptiste, Any word on this?
Warner On Jun 19, 2014, at 10:22 AM, Nathan Whitehorn <nwhiteh...@freebsd.org> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
