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?
> 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.
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.
-- Petr
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
