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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
