Hi,
Fedora carries some "C/C++" "template"/"header-only" packages (Packages which contain C/C++-headers only).
Typically, these packages are being built "BuildArch: noarch".
== These packages are supposed to be arch-independent.
In reality, many of these packages often are wrapper headers, trying to wrap to something highly OS-/arch-dependent, from system-headers and compiler built-ins defines.
I.e. though these packages are supposed to be arch-independent, there is no guarantee nor check whether these packages actually are arch-independent.
I am proposing to:
Proposal:
All "C/C++-template/header-only packages" must be built using an "arch'ed BuildArch", with the resulting binary packages implemented as "Arch: noarch"-subpackages.
Benefits:
- This would assure such packages would be built on all architectures Fedora supports and not only the architecture noarch-packages are being built.
- This would exercise potentially existing configuration-scripts on all architectures and would allow to exercise test-scripts rsp. coding examples (which can be regarded as compilation-checks) on all Fedora supported architectures.
Comments, opinions?
Ralf
On 2012-10-15 11:05, Ralf Corsepius wrote:
Hi,
Fedora carries some "C/C++" "template"/"header-only" packages (Packages which contain C/C++-headers only).
Typically, these packages are being built "BuildArch: noarch".
== These packages are supposed to be arch-independent.
In reality, many of these packages often are wrapper headers, trying to wrap to something highly OS-/arch-dependent, from system-headers and compiler built-ins defines.
I.e. though these packages are supposed to be arch-independent, there is no guarantee nor check whether these packages actually are arch-independent.
I am proposing to:
Proposal:
All "C/C++-template/header-only packages" must be built using an "arch'ed BuildArch", with the resulting binary packages implemented as "Arch: noarch"-subpackages.
Benefits:
- This would assure such packages would be built on all architectures
Fedora supports and not only the architecture noarch-packages are being built.
- This would exercise potentially existing configuration-scripts on
all architectures and would allow to exercise test-scripts rsp. coding examples (which can be regarded as compilation-checks) on all Fedora supported architectures.
Comments, opinions?
If the packages do turn out to be arch-specific (e.g. different constants for different architectures), the use of noarch subpackages would cause the build to fail, which _would_ be a good thing. To fix that, the packager would either have to use tricks like the ones often found to provide multi-arch support for library-config scripts, or making the packages arch-specific, which would probably result in multi-arch conflicts unless the install paths were made arch-specific too.
So I think this is a good plan except I wouldn't make the use of noarch subpackages a MUST - it would be OK to have them arch-specific as long as they didn't have multi-arch conflicts (so for example i386 and x86_64 could be installed in parallel).
Paul.
On 10/15/2012 01:03 PM, Paul Howarth wrote:
On 2012-10-15 11:05, Ralf Corsepius wrote:
Hi,
Fedora carries some "C/C++" "template"/"header-only" packages (Packages which contain C/C++-headers only).
Typically, these packages are being built "BuildArch: noarch".
== These packages are supposed to be arch-independent.
In reality, many of these packages often are wrapper headers, trying to wrap to something highly OS-/arch-dependent, from system-headers and compiler built-ins defines.
I.e. though these packages are supposed to be arch-independent, there is no guarantee nor check whether these packages actually are arch-independent.
I am proposing to:
Proposal:
All "C/C++-template/header-only packages" must be built using an "arch'ed BuildArch", with the resulting binary packages implemented as "Arch: noarch"-subpackages.
Benefits:
- This would assure such packages would be built on all architectures
Fedora supports and not only the architecture noarch-packages are being built.
- This would exercise potentially existing configuration-scripts on
all architectures and would allow to exercise test-scripts rsp. coding examples (which can be regarded as compilation-checks) on all Fedora supported architectures.
Comments, opinions?
If the packages do turn out to be arch-specific (e.g. different constants for different architectures), the use of noarch subpackages would cause the build to fail, which _would_ be a good thing. To fix that, the packager would either have to use tricks like the ones often found to provide multi-arch support for library-config scripts, or making the packages arch-specific, which would probably result in multi-arch conflicts unless the install paths were made arch-specific too.
So I think this is a good plan except I wouldn't make the use of noarch subpackages a MUST - it would be OK to have them arch-specific as long as they didn't have multi-arch conflicts (so for example i386 and x86_64 could be installed in parallel).
Good point - My proposal needs refinements ;)
In my posting above, I am referring to "C/C++-template/headers-only" which currently are shipped or about to be shipped "noarch" in Fedora [1].
Ralf
[1] Background of this RFD is me having tripped over such "lack of generality" bug when activating the code-examples and test-building such a noarched "C-/C++-header-only" package in a i386-mock instead of x86_64-environment, some weeks ago (Unfortunately, ATM, I don't recall which package it was.)
packaging@lists.fedoraproject.org