Michael Schwendt wrote:
On Thu, 19 Apr 2007 16:40:48 +0200, Hans de Goede wrote:
Michael Schwendt wrote:
No. The pushscript makes available the i386 development packages for
x86_64, so you can develop for i386 on x86_64.
And does this in a very stupid way, for some reason in your reply you didn't
bother to react to this:
What is stupid?
That having a -devel subpackage isn't a very smart way to decide wether or not
a package should get its i386 version dragged into the x86_64 tree, not smart
== stupid. Why not add some additional heuristics using stuff that actually is
in the package. The advantages are huge, less i386 packages in the x86_64 tree
makes for less mirrorbandwidth wasted, smaller repodata and thus faster user
experience, etc.
---
No this sounds like a BAD solution to me. We are going to have this problem for
every non noarch perl / python / ruby / xxx package that happens to split of a
-devel package (for example because of .pc files).
---
Where I was talking about the pygame-devel issue,
pygame-devel is gone as it was broken. It required the main package
without reason, and the main package required 32-bit Python which is not
available for x86_64. The alternative would have been to blacklist
pygame-devel.
How was it broken? Now we have header files installed under /usr/include in a
main package, and that is somehow less broken?
simply putting all .i386
packages which have a -devel subpackage / provides in the x86_64 tree is wrong.
Stupid. Wrong. Why? White-list, black-list, what do you refuse to
understand?
Again repeating myself, as you still have not addressed this:
"We are going to have this problem for every non noarch perl / python / ruby /
xxx package that happens to split of a -devel package (for example because of
.pc files)."
This is what one calls broken by design. Yet another example, pygtkglext, which
is a python wrapper for pygtkglext has a -devel package for the .pc files (as
it must according to the guidelines). Thus now we have pygtkglext.i386 in the
x86_64 tree, which is not what we want AFAIK. You want me to clarify how the
push script could become smarter? :
1) Blacklist by default Py* PY* py* perl* php* and probably others
2) If when resolving deps not all deps can be resolved because this requires
i386 packages from core which core hasn't put in the x86_64 tree, then don't
include the package with the unresolved deps in the x86_64 tree
This will fix the pygtkglext example and would also have meant that there would
have been no problems surrounding pygame.
IMO, the gnumeric-devel package is broken and should be eliminated.
It would not be the first -devel package which should never have been
published.
gnumeric (and pygame, pygtkglext) are all just examples, this is about the fact
that the base principle is broken (or oversimplified if you prefer to call it
that). Repeating myself yet another time: "I agree that the -devel subpackage
of gnumeric is a strange beast and probably not necessary, but thats not the
discussion here" IOW I'll give you the point that we might be better of without
gnumeric having a -devel, I say might as I haven't looked into this yet.
Regards,
Hans
--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
