Re: ABI/architecture identification for packages
Quoting Bruce Cran br...@cran.org.uk (from Tue, 20 Mar 2012 14:26:42 +):
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?
Bye,
Alexander.
--
Preserve wildlife -- pickle a squirrel today!
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Wed, Mar 21, 2012 at 02:34:03PM +0100, Alexander Leidinger wrote:
Quoting Bruce Cran br...@cran.org.uk (from Tue, 20 Mar 2012 14:26:42 +):
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 :)
regards,
Bapt
pgp4ILTHfkUB2.pgp
Description: PGP signature
Re: ABI/architecture identification for packages
Quoting Baptiste Daroussin b...@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 br...@cran.org.uk (from Tue, 20 Mar 2012
14:26:42 +):
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?
Bye,
Alexander.
--
Men aren't attracted to me by my mind.
They're attracted by what I don't mind...
-- Gypsy Rose Lee
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
Baptiste Daroussin wrote: 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 Baptiste, if ABI/arch ids will leak out to port Makefiles (i.e. I will need to care about them), then please leave them matching to the usual FreeBSD arch names, i.e. i386 and amd64, not the new ones. For reasons of consistency. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Wed, Mar 21, 2012 at 03:59:38PM +0100, Alexander Leidinger wrote:
Quoting Baptiste Daroussin b...@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 br...@cran.org.uk (from Tue, 20 Mar 2012
14:26:42 +):
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
pgpWsIs0MeARm.pgp
Description: PGP signature
Re: ABI/architecture identification for packages
On Wed, Mar 21, 2012 at 05:18:07PM +0200, Vitaly Magerya wrote: Baptiste Daroussin wrote: 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 Baptiste, if ABI/arch ids will leak out to port Makefiles (i.e. I will need to care about them), then please leave them matching to the usual FreeBSD arch names, i.e. i386 and amd64, not the new ones. For reasons of consistency. The is the reason of the or :) the problem will occurs with the old way when arm and mips package support will be generalized regards, Bapt pgpZ5M5rFo52V.pgp Description: PGP signature
Re: ABI/architecture identification for packages
In message 20120319215802.gc1...@azathoth.lan, Baptiste Daroussin writes: On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) Given how sparse this name-space is, you'll have less than 50 different values, you might want to consider something more compact, such as a single letter for all components, and the version number last: X2F9= x64-32-freebsd-9 X4F10 = x64-64-freebsd-10 A2FB9 = arm-32-freebsd-eb_oabi-9 By the time we run out of ASCII or even Unicode characters, we have other problems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
Hello. On 03/20/2012 10:24, Poul-Henning Kamp wrote: In message20120319215802.gc1...@azathoth.lan, Baptiste Daroussin writes: On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote: here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) Given how sparse this name-space is, you'll have less than 50 different values, you might want to consider something more compact, such as a single letter for all components, and the version number last: X2F9= x64-32-freebsd-9 X4F10 = x64-64-freebsd-10 A2FB9 = arm-32-freebsd-eb_oabi-9 By the time we run out of ASCII or even Unicode characters, we have other problems. And what is a purpose of making non-human-friendly platform identifiers? I think, you'll gain nothing by this, but will create an unnecessary complication. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Tue, Mar 20, 2012 at 06:24:37AM +, Poul-Henning Kamp wrote: In message 20120319215802.gc1...@azathoth.lan, Baptiste Daroussin writes: On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) Given how sparse this name-space is, you'll have less than 50 different values, you might want to consider something more compact, such as a single letter for all components, and the version number last: X2F9 = x64-32-freebsd-9 X4F10 = x64-64-freebsd-10 A2FB9 = arm-32-freebsd-eb_oabi-9 By the time we run out of ASCII or even Unicode characters, we have other problems. While I tend to agree to compact/short identifier on the principle, I don't really like the obfuscation it brings, I prefer this to remain humain readable, at a point or another it could be shown to users (you are trying to install an x86-64-freebsd-10 package on a x86-32-freebsd-9 system if more understandable than you are trying to install a X4F10 package on a X2F9 system.) regards, Bapt pgptXx1a4l73k.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) arch can be one of the following: - x86 for i386 and amd64 (discussed with kib) - powerpc for powerpc and powerpc64 - arm - mips - sparc class may be: - 32 bits - 64 bits os will always be freebsd :) (lower case) majorversion the freebsd major version (10 9 8) achi_specific_extension currently only mips and arm are concerned, for arm could be: el_oabi eb_oabi el_eabi eb_eabi (I don't know how to get arm version or hardfp/softfp from the elf) for mips I don't know much. for ia64, I have strictly no idea what I should set. Everything is read from the elf file for example: x86-64-freebsd-10 x86-32-freebsd-8 arm-32-freebsd-10-el_oabi Please help me to improve this to get the better identification to have the best possible to determine which package can be installed where. while proposing information please tell me how to get the information (dynamically) regards, Bapt Another question (by rwatson) that comes here is should we keep the architecture names that freebsd uses to avoid confusion or should we try to use more accurate names? powerpc-64-freebsd-9 - powerpc64-64-freebsd-9 x86-32-freebsd-9 - i386-32-freebsd-9 x86-64-freebsd-9 - amd64-64-freebsd-9 etc. An example of implementation can be find here: https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_elf.c#L157 PS: Feel free to submit fixes/improvements to the code :) regards, Bapt pgpD0DjAlcHIL.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On Tue, Mar 20, 2012 at 10:19:36AM +0100, Baptiste Daroussin wrote:
On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote:
Hi all,
In order to identify architectures I need to find a uniq id for every
possibilities (for pkgng)
here is the identification I propose:
arch-class-os-majorversion(-archi_specific_extension)
arch can be one of the following:
- x86 for i386 and amd64 (discussed with kib)
- powerpc for powerpc and powerpc64
- arm
- mips
- sparc
class may be:
- 32 bits
- 64 bits
os will always be freebsd :) (lower case)
majorversion the freebsd major version (10 9 8)
achi_specific_extension currently only mips and arm are concerned,
for arm could be:
el_oabi
eb_oabi
el_eabi
eb_eabi
(I don't know how to get arm version or hardfp/softfp from the elf)
for mips I don't know much.
for ia64, I have strictly no idea what I should set.
Everything is read from the elf file
for example:
x86-64-freebsd-10
x86-32-freebsd-8
arm-32-freebsd-10-el_oabi
Please help me to improve this to get the better identification to have the
best
possible to determine which package can be installed where.
while proposing information please tell me how to get the information
(dynamically)
regards,
Bapt
Another question (by rwatson) that comes here is should we keep the
architecture
names that freebsd uses to avoid confusion or should we try to use more
accurate
names?
powerpc-64-freebsd-9 - powerpc64-64-freebsd-9
x86-32-freebsd-9 - i386-32-freebsd-9
x86-64-freebsd-9 - amd64-64-freebsd-9
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.
etc.
An example of implementation can be find here:
https://github.com/pkgng/pkgng/blob/master/libpkg/pkg_elf.c#L157
PS: Feel free to submit fixes/improvements to the code :)
regards,
Bapt
pgpRB2KwxM3NO.pgp
Description: PGP signature
Re: ABI/architecture identification for packages
IMHO, 32 / 64 = easily parsable and represent integer. i386/amd64 - wellknown names, but this info about processor bits not lies in math. My point is i386 is arch, so can be kept, while 32 is processor bit count. If you'll keep 32/64 various checks in side software will be simple (if you have 32 bit processor, then this info is bundled in 32), while if you consider using i386 string as storage of information about 32 bit, it not so elegant. Also, linuxes has come to i386- i586- i686- mess, and many their scripts looks overbloated when they checks if system really 32 bit. Just my point of view :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
We should probably pad the version number, and shorten things up.. similar to: package-1.2-fbsd09.1-x86.pkg package-1.2-fbsd09.1-x64.pkg package-1.2-fbsd09.1-ppc.pkg package-1.2-fbsd09.1-ppc64.pkg package-1.2-fbsd09.1-arm.pkg For app Package version 1.2, on FreeBSD 9.1 drop the .1 for .0 versions. The reason for the padding is to help with sorting, at least until freebsd 100.0 comes out. :P Chuck Burns On 3/20/2012 5:40 AM, Alexander Yerenkow wrote: IMHO, 32 / 64 = easily parsable and represent integer. i386/amd64 - wellknown names, but this info about processor bits not lies in math. My point is i386 is arch, so can be kept, while 32 is processor bit count. If you'll keep 32/64 various checks in side software will be simple (if you have 32 bit processor, then this info is bundled in 32), while if you consider using i386 string as storage of information about 32 bit, it not so elegant. Also, linuxes has come to i386- i586- i686- mess, and many their scripts looks overbloated when they checks if system really 32 bit. Just my point of view :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
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
--
Bruce Cran___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Tue, Mar 20, 2012 at 07:20:52AM -0500, Chuck Burns wrote: We should probably pad the version number, and shorten things up.. similar to: package-1.2-fbsd09.1-x86.pkg package-1.2-fbsd09.1-x64.pkg package-1.2-fbsd09.1-ppc.pkg package-1.2-fbsd09.1-ppc64.pkg package-1.2-fbsd09.1-arm.pkg For app Package version 1.2, on FreeBSD 9.1 drop the .1 for .0 versions. The reason for the padding is to help with sorting, at least until freebsd 100.0 comes out. :P Chuck Burns I'm not on changing the package name, this information will be in the manifest. the packagename will remain name-version.txz regards, Bapt pgpFvahJw3xYO.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On Tue, Mar 20, 2012 at 02:26:42PM +, Bruce Cran wrote:
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
Yes, we do want to support this.
In which form, and when, I have no good answer.
We can propose some name for the architecture when the work starts.
pgpK9JMzXmuRw.pgp
Description: PGP signature
Re: ABI/architecture identification for packages
on 20/03/2012 16:39 Baptiste Daroussin said the following: On Tue, Mar 20, 2012 at 07:20:52AM -0500, Chuck Burns wrote: We should probably pad the version number, and shorten things up.. similar to: package-1.2-fbsd09.1-x86.pkg package-1.2-fbsd09.1-x64.pkg package-1.2-fbsd09.1-ppc.pkg package-1.2-fbsd09.1-ppc64.pkg package-1.2-fbsd09.1-arm.pkg For app Package version 1.2, on FreeBSD 9.1 drop the .1 for .0 versions. The reason for the padding is to help with sorting, at least until freebsd 100.0 comes out. :P Chuck Burns I'm not on changing the package name, this information will be in the manifest. the packagename will remain name-version.txz So no plans for cross-arch package repos? :) IMO, it could be useful to reflect arch metadata in the package name. BTW, some packaging systems also have a noarch indicator for packages that contain purely stuff like documentation or images (or shell scripts, etc). -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Tue, Mar 20, 2012 at 05:18:12PM +0200, Andriy Gapon wrote: on 20/03/2012 16:39 Baptiste Daroussin said the following: On Tue, Mar 20, 2012 at 07:20:52AM -0500, Chuck Burns wrote: We should probably pad the version number, and shorten things up.. similar to: package-1.2-fbsd09.1-x86.pkg package-1.2-fbsd09.1-x64.pkg package-1.2-fbsd09.1-ppc.pkg package-1.2-fbsd09.1-ppc64.pkg package-1.2-fbsd09.1-arm.pkg For app Package version 1.2, on FreeBSD 9.1 drop the .1 for .0 versions. The reason for the padding is to help with sorting, at least until freebsd 100.0 comes out. :P Chuck Burns I'm not on changing the package name, this information will be in the manifest. the packagename will remain name-version.txz So no plans for cross-arch package repos? :) IMO, it could be useful to reflect arch metadata in the package name. BTW, some packaging systems also have a noarch indicator for packages that contain purely stuff like documentation or images (or shell scripts, etc). This is then plan except that I prefer calling it any than noarch :) No need to change the package name for that. If you want the package name to reflect the real abi it will be from far too long :) The indication is in the the repository metadata, it is enough most of the time, if we are on adding it to the package name what do you want to see in ? OS? majorversion? arch? 32/64bits? incompatible abi/extension? You will get the same problem that I'm trying to solve except that it will gives you very very long package names. regards, Bapt pgpEIOcIwI2QW.pgp Description: PGP signature
ABI/architecture identification for packages
Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) arch can be one of the following: - x86 for i386 and amd64 (discussed with kib) - powerpc for powerpc and powerpc64 - arm - mips - sparc class may be: - 32 bits - 64 bits os will always be freebsd :) (lower case) majorversion the freebsd major version (10 9 8) achi_specific_extension currently only mips and arm are concerned, for arm could be: el_oabi eb_oabi el_eabi eb_eabi (I don't know how to get arm version or hardfp/softfp from the elf) for mips I don't know much. for ia64, I have strictly no idea what I should set. Everything is read from the elf file for example: x86-64-freebsd-10 x86-32-freebsd-8 arm-32-freebsd-10-el_oabi Please help me to improve this to get the better identification to have the best possible to determine which package can be installed where. while proposing information please tell me how to get the information (dynamically) regards, Bapt pgprvLkMjQp0L.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On Mon, Mar 19, 2012 at 10:35:08PM +0100, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) arch can be one of the following: - x86 for i386 and amd64 (discussed with kib) - powerpc for powerpc and powerpc64 - arm - mips - sparc class may be: - 32 bits - 64 bits os will always be freebsd :) (lower case) majorversion the freebsd major version (10 9 8) achi_specific_extension currently only mips and arm are concerned, for arm could be: el_oabi eb_oabi el_eabi eb_eabi (I don't know how to get arm version or hardfp/softfp from the elf) Fixed thanks cognet just missing the arm version now for mips I don't know much. for ia64, I have strictly no idea what I should set. Everything is read from the elf file for example: x86-64-freebsd-10 x86-32-freebsd-8 arm-32-freebsd-10-el_oabi Please help me to improve this to get the better identification to have the best possible to determine which package can be installed where. while proposing information please tell me how to get the information (dynamically) regards, Bapt pgp60gsUuHxha.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On Mon, Mar 19, 2012 at 5:35 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) arch-class-os-majorversion(-archi_specific_extension) os will always be freebsd :) (lower case) So why bother? -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Mon, Mar 19, 2012 at 06:01:23PM -0400, Eitan Adler wrote: On Mon, Mar 19, 2012 at 5:35 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) arch-class-os-majorversion(-archi_specific_extension) os will always be freebsd :) (lower case) So why bother? because some people from other oses are interested in pkgng (not work started on this) because some vendors might want to change it. So I read it from the elf note section regards, Bapt pgpE66l8Oqw60.pgp Description: PGP signature
Re: ABI/architecture identification for packages
On 19/03/2012 22:04, Baptiste Daroussin wrote: On Mon, Mar 19, 2012 at 06:01:23PM -0400, Eitan Adler wrote: On Mon, Mar 19, 2012 at 5:35 PM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) arch-class-os-majorversion(-archi_specific_extension) os will always be freebsd :) (lower case) So why bother? because some people from other oses are interested in pkgng (not work started on this) because some vendors might want to change it. So I read it from the elf note section What about if the package happens to contain linux executables? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: ABI/architecture identification for packages
On 03/19/12 14:35, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) arch can be one of the following: - x86 for i386 and amd64 (discussed with kib) - powerpc for powerpc and powerpc64 - arm - mips - sparc class may be: - 32 bits - 64 bits os will always be freebsd :) (lower case) majorversion the freebsd major version (10 9 8) achi_specific_extension currently only mips and arm are concerned, for arm could be: el_oabi eb_oabi el_eabi eb_eabi One brief comment here: the output of uname -p (arm, armeb, etc.) is meant to encode the ABI completely. All platforms with the same uname -p should be able to execute each other's binaries. Why not just a sequence of `uname -p`-`uname -s`-`uname -r` (or some subset of uname -r)? That should be enough to completely encode compatibility information on almost any operating system. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ABI/architecture identification for packages
On Mon, Mar 19, 2012 at 5:41 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 03/19/12 14:35, Baptiste Daroussin wrote: Hi all, In order to identify architectures I need to find a uniq id for every possibilities (for pkgng) here is the identification I propose: arch-class-os-majorversion(-archi_specific_extension) arch can be one of the following: - x86 for i386 and amd64 (discussed with kib) - powerpc for powerpc and powerpc64 - arm - mips - sparc class may be: - 32 bits - 64 bits os will always be freebsd :) (lower case) majorversion the freebsd major version (10 9 8) achi_specific_extension currently only mips and arm are concerned, for arm could be: el_oabi eb_oabi el_eabi eb_eabi One brief comment here: the output of uname -p (arm, armeb, etc.) is meant to encode the ABI completely. All platforms with the same uname -p should be able to execute each other's binaries. Why not just a sequence of `uname -p`-`uname -s`-`uname -r` (or some subset of uname -r)? That should be enough to completely encode compatibility information on almost any operating system. The only tricky thing is that many OSes don't agree on branding. I don't know how far bapt and crew are willing to go to make pkgng OS agnostic. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
