On 09/06/16 08:02 +0000, Petr Pisar wrote:
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.
Great, sounds good.
I'm in favour of breaking any packages that say Requires: gcc%{?_isa}
so they have to be fixed.
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.
The alternative would be for gcc.x86_64 to unconditionally install the
32-bit packages, even though most users will not use -m32 and so won't
need them. Another alternative would be to build gcc with
--disable-multilib so you can't use -m32, which would be annoying and
inconvenient for users.
What you call broken is a pragmatic engineering decision.
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 what if you just want to build "int main() { }" with -m32? Why
should building 32-bit software work out-of-the-box when using
additional libraries from a -devel package, but not otherwise?
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 being rather melodramatic.
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.
Installing a -devel package is neither building nor running software.
To build anything you need the toolchain, but installing headers is
not the same as building against them.
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.
That's what the draft now says:
https://fedoraproject.org/wiki/C_and_C%2B%2B_v2
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
