On 08/06/16 12:00 +0000, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
On 08/06/16 08:38 +0000, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
On 08/06/16 07:37 +0000, Petr Pisar wrote:
Guidelines require devel packages to be architecture specific (no
BuildArch: noarch). Guidelines require having dependencies between
architecture specific packages restricted to the architecture
(Requires: foo-devel%{?_isa}). C guildelines require depending on "gcc"
for standard C library header files.
Files in devel packages usually include standard C library header
files, thus one needs to "Require: gcc%{?_isa}" from the devel packages.
Why?
Because "#include <stdlib.h>" fails without stdlib.h on the system,
you need to depend on something that provides the stdlib.h. And
guidelines says the provider is "gcc".
So you should require gcc, not gcc%{?_isa}
And what about all the %{?_isa} recommendations in the main guidelines
<https://fedoraproject.org/wiki/Packaging:Guidelines> (search for the
string, it's scattered over all the text)?
Should I interpret the C guidelines in such way that the %_isa rules do not
apply to them because, ehm, gcc is special?
'gcc' *is* special, because it's the special case that all C packages
depend on (and similarly for gcc-c++ for C++).
Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
gcc seems sensible! :-)
I can see how you might need libstdc++-devel%{?_isa} or other
components of GCC, but those *are* multilibbed, so you can have both
libstdc++-devel.i686 and libstdc++-devel.x86_64 installed at the same
time.
Last I was those are implementation details and I should depend on GCC
instead. You should know because you were involved in the discussion
that leads to the C packaging guidelines.
The guidelines say:
"You need not include a BuildRequires or Requires on glibc-headers, or
any other core C or C++ implementation package unless you have a
specific and special need"
A 64-bit package which requires 32-bit compilation seems like a fairly
specific need, so it seems reasonable to require glibc-headers.i686
directly in that case (or more accurately, glibc-headers%{arch32}
where that macro is set appropriately).
What other problems are you trying to solve?
The basic motivation for %{?_isa} is to prevent from mixing primary and
secondary multilib packages. It was shown package managers are not good
in enforcing primary architecture. Therefore the %{?_isa} rule was set
in place.
In any case, the solution is not to make gcc multilib-installable (as
has been explained repeatedly, that isn't useful, the 'gcc' binaries
installed by gcc.x86_64 already support 32-bit compilation perfectly
well).
If this is so, I will go to FPC with request the ammend the C guidelines
with explicit discourage of %{?_isa} on gcc because the main
architecture supports the secondary targets and because gcc is not
multilib safe.
I think -devel packages should not "Require: gcc" at all. Not with
%_isa and not without it.
To actually compile something using those headers you need the C (or
C++) build environment installed anyway, i.e. you need 'gcc' (or
'gcc-c++') installed so there's no benefit to the package giving it as
a requirement.
If you want to install the foobar-devel.i686 package on x86_64 and
compile 32-bit software with those 32-bit headers you'll need to
manually install glibc-headers.i686, but that's true even if you just
want to compile a "Hello, world!" as a 32-bit C program on x86_64.
So simply don't add a Requires to -devel packages for the build env.
Don't Require: gcc and don't Require: glibc-headers. If a -devel
package currently has Requires: glibc-headers%{?_isa} then IMHO that
Requires should be removed, not replaced with gcc or gcc%{?_isa}
(unless for some special reason the package really does need
glibc-headers explicitly, not just in order to provide a working build
env).
I'll update the draft for V2 of the C/C++ Packaging Guidelines to say
that.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
