On 2016-06-08, Jonathan Wakely <jwakely(a)fedoraproject.org> wrote:
On 08/06/16 15:43 +0000, Petr Pisar wrote:
>On 2016-06-08, Jonathan Wakely <jwakely(a)fedoraproject.org> 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?
It would save space on mirrors. It would save QA capacity. It would reveal
that run-requiring secondary architecture gcc does not work as expected
sooner.
>> 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.
That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit
executable without the i686 toolchain packages. It sounds like broken
dependencies.
This is independent of foobar-devel.
But with foobar-devel you would get full user experience in contrast
to a source code out of the repository. That would make distribution
easier to use.
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.
From my point of view, broken dependencies make dependency graph broken
and that makes all the tools on top of the graph (repoclosure, dnf etc.)
unreliable. We even cannot answer a simple question what packages should
go into a repository.
Every time a new distribution is going to be released, I'm asked
by release engineers what i686 packages should be put into x86_64
repository. They don't know. I don't know. I also get bug reports from
QE that some of those packages are not multilib safe. I would fix them
sooner if I knew that they are handled as multilib. But again I have no
way how to know that.
I tried to solve it by fixing the dependency graph. But obviously it's
too hard problem and many people rather say don't do that, it's a minor
use case.
Ok. Let's have a broken distribution.
You're misrepresenting things to make it sound complicated.
Probably. I understood that header files are provided by gcc and
that it's independed from build or run time.
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.
Then people will ask what to depend on when including toolchain headers.
The guidelines should answer it like: Depend on nothing, this
dependency is left undeclared intentionally because a user is supposed
to install a toolchain of his choice manually.
-- Petr