broken deps outside of packagers control

[Hans de Goede]

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