[Patch] Using MACHINE_ARCH identifiers in pkg

[Warner Losh]

Hey Baptiste,

Any word on this?

Warner

On Jun 19, 2014, at 10:22 AM, Nathan Whitehorn <nwhitehorn at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140626/3863e0ad/attachment.sig>