ABI/architecture identification for packages

[Baptiste Daroussin]

On Wed, Mar 21, 2012 at 03:59:38PM +0100, Alexander Leidinger wrote:
> Quoting Baptiste Daroussin <bapt at freebsd.org> (from Wed, 21 Mar 2012  
> 14:59:20 +0100):
> 
> > On Wed, Mar 21, 2012 at 02:34:03PM +0100, Alexander Leidinger wrote:
> >> Quoting Bruce Cran <bruce at cran.org.uk> (from Tue, 20 Mar 2012  
> >> 14:26:42 +0000):
> >>
> >> > On 20 Mar 2012, at 10:20, Konstantin Belousov wrote:
> >> >
> >> >> i386-32 and amd64-64 is weird and confusing.
> >> >>
> >> >> IMO, you should go either with x86-{32,64} names, or with i386/amd64,
> >> >> not with a mix.
> >> >
> >> > Would we ever want to support something like x32 from Linux (which
> >> > might be amd64-32)?
> >> > http://www.linuxplumbersconf.org/2011/ocw/sessions/531
> >>
> >> Not related to x32, but related to the Linux keyword (yes, I'm in the
> >> wrong branch of this thread, but I don't have the root anymore):
> >>
> >> Can you please explain how the linuxulator ports (linux_base-*) fit  
> >> into this?
> >>
> >> linux_base-f10 contains 32bit linux binaries, which run in the
> >> linuxulator on i386 and amd64. If someone steps up and finishes the
> >> 64bit linux emulation on amd64, we would be able to use a
> >> linux_base(32) and a linux_base64 (or however we want to name them
> >> then) on amd64 (both at the same time). The content of the packages
> >> generated on i386 can be used on amd64 (both are generated from the
> >> same linux binary RPMs and the few FreeBSD modifications are rm's,
> >> symlinks and config changes).
> >>
> >> Can you please explain and/or give examples which kind of metadata
> >> those ports would get?
> >
> > for packages currently their will be two possible chain for the abi:
> > the abi defined here or any
> >
> > any will be for scripts, data, etc.
> >
> > I was thinking about giving a multi arch possibilities for packages  
> > for example:
> >
> > arch: ["freebsd:9:x86:32", "freebsd:9:x86:64"]
> >
> > when a package can be installed in both i386 and amd64
> >
> > and maybe in the Makefile:
> >
> > PKGARCH=	i386 amd64
> >
> > or
> >
> > PKGARCH=	x86:32 x86:64
> >
> > not decided yet
> >
> > for scripts:
> >
> > PKGARCH=	any
> >
> > But I haven't decided yet :)
> 
> This means that you do not try to compute this, you want to rely on  
> metadata from humans.
> 
> How to you want to handle the common FreeBSD native port (has to be  
> compiled, can be compiled without problems on all FreeBSD  
> architectures (e.g. the "Hello World." program), the binary only works  
> on the architecture it was compiled for)? I assume you do not want to  
> add PKGARCH=$(NATIVE_ARCH) to every port. Maybe  
> PKGARCH?=$(NATIVE_ARCH) in bsd.port.mk?

well is pkgarch isn't defined pkgng will fall back on the system one, so you do
not need to add it in bsd.port.mk neither in the port Makefile

regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120321/f0333e2e/attachment.pgp