On 2016-06-08, Jonathan Wakely <jwakely@xxxxxxxxxxxxxxxxx> wrote:
> 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?
>
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
