On 08/06/16 15:43 +0000, Petr Pisar wrote:
On 2016-06-08, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for
gcc seems sensible! :-)
Why both gcc.i686 and gcc.x86_64 are available in the x86_64 repository?
Shouldn't gcc.i686 be expelled from the x86_64 repository?
Maybe, yes. Is it that important to do so though?
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.
That's true until you read your next paragraph which shows the benefit:
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.
If I install gcc and foobar-devel.i686, I expect I can build 32-bit
software against fooboar.
Think about it: you can't build 32-bit software **at all** unless you
install glibc-devel.i686, not even just "int main() { }" with no
headers at all.
This is independent of foobar-devel.
And it's not a very common case anyway. If you need to build 32-bit
code on a 64-bit system then install glibc-devel.i686 and then it's
done, it doesn't need to be done again.
Making a big deal out of it to support a minor use case just doesn't
seem that important to me.
If you have so well structured toolchain packages as Jakub described,
why not to allow dependency on glibc-headers%{?_isa} (or some other
virtual provide common to all toolchains)?
I'd like release engineers to join this discussion. I know horrible
storries about broken multilib. Nobody knows why a package should or
shouldn't support multilib. The result is repository compose process
involves various package name matching rules, and white and black lists
and still nobody can verify the output is correct.
I believe precise dependency specification would help to automate the
multilib tests. But stepping back ("don't require glibc-headers, require
gcc", "oh no, don't require gcc at all") does not make the multilib
life better.
You're misrepresenting things to make it sound complicated.
The packaging guidelines say to use BuildRequires to build C and C++
packages. I want to extend those guidelines to say don't add Requires:
gcc just because you isntall headers. That's not confusing or
contradictory.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
