[Patch] Using MACHINE_ARCH identifiers in pkg

Nathan Whitehorn nwhitehorn at freebsd.org
Wed Aug 13 22:49:12 UTC 2014


On 06/26/14 14:30, 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.
>
> regards,
> Bapt

Anything you need help with here? We seem to be moving pretty rapidly 
toward having official packages for more platforms, which is great, but 
it would be nice to have this in beforehand to reduce the number of 
needed compatibility shims on the package server.
-Nathan


More information about the freebsd-ports mailing list