svn commit: r258310 - head/release

[Glen Barber]

On Tue, Nov 19, 2013 at 05:29:24AM +0900, Hiroki Sato wrote:
> Glen Barber <gjb at FreeBSD.org> wrote
>   in <20131118195506.GT1643 at glenbarber.us>:
> 
> gj> > gj> -export PKG_ABI="freebsd:$(echo ${REVISION} | tr -d '.0'):x86:64"
> gj> > gj> +export PKG_ABI="freebsd:$(echo ${REVISION} | sed -e 's/\.[0-9]//'):x86:64"
> gj> >
> gj> >  PKG_ABI=freebsd:${REVISION%.[0-9]*}:x86:64 is simpler than invoking
> gj> >  tr or sed.  However, pkg-stage.sh should have a mapping rule from
> gj> >  TARGET and TARGET_ARCH, not in arch specific config files, I think.
> gj> >  Other than the package list, variables are not arch-specific.
> gj> >
> gj> The pkg(8) ABI does not map directly to anything we use ('amd64' or
> gj> 'i386') unfortunately.
> 
>  Yes, it is true that it does not map TARGET/TARGET_ARCH directly.
>  What I mean is that it can be easily translated in pkg-stage.sh by
>  adding a mapping rule there like this:
> 
>   case ${TARGET}:{TARGET_ARCH} in
>   amd64:*) PKG_ABI=x86:64 ;;
>   ...
>   esac
> 

That is kind of the problem though.  The ABI for amd64 is not x86:64, it
is:
    $(uname -s | tr '[:upper:]' '[:lower:]'):${REVISION%.[0-9]}:x86:64

I do plan to redo quite a bit of this script, but it is good enough for
a solution to the "we have nothing at all right now" problem for
10.0-RELEASE.

>  Depending files in arch-specific directory makes maintenance
>  difficult when the number of archs and combinations of
>  TARGET/TARGET_ARCH increase.  It can happen when arm and mips are
>  handled in make release and the package server.  Eliminating/reducing
>  manually-configured variables which can be derived from other ones is
>  always a good practice.
> 
> gj> >  Does this guarantee that the packages downloaded by pkg(8) are for a
> gj> >  specific release?  And I think fetching packages can be done just
> gj> >  after svn co stage in release.sh.  Collecting up necessity of network
> gj> >  access (including fetching distfiles for docproj) before entering the
> gj> >  chroot environment makes redoing the release build easier.
> gj> >
> gj>
> gj> I don't think it has been discussed yet where packages built for
> gj> a specific release will exist.  Anyway, I would like to avoid directory
> gj> hierarchy pollution outside of the dvd/ directory, this is why I use it
> gj> for PKG_CACHEDIR directly.
> 
>  So I think it should be discussed and we should make the script to
>  consistently fetch the package set built from the release branch (or
>  head for stable or snapshots) in the ports tree.  While I guess the
>  current one simply fetches the latest packages, the release iso
>  images must have packages which correspond to ports.txz.
> 

Agreed.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20131118/d991ff7e/attachment.sig>