broken deps outside of packagers control

[Michael Schwendt]

On Thu, 19 Apr 2007 22:36:10 +0200, Hans de Goede wrote:

> >> 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.

What a great definition!

> Why not add some additional heuristics using stuff that actually is 
> in the package.

You are free to contribute something like that. Any -devel package, which
would be excluded, could still be in the dependency-chain of another
-devel package, which would be included. The more gets excluded, the
easier the dep-chains can break. In other words, excluding potential
multi-lib development packages is bad. More about this further below,
since you mentioned dep-checking...

> 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.

It's not implemented yet, the results are unknown, don't guess whether the
advantages would be huge. Actually, we have lots of valid i386 -devel
packages in the tree. But I'm not convinced that the current multi-lib
strategy is good. A separate i386 repo is available, and the i386 pkgs in
the x86_64 cause several problems which are documented by many users
(e.g. yum installing both i386 and x86_64 and things like that).

> >> 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?

I've rexamined pygame in devel and need to correct myself. 3 of the 4
headers can be used to call pygame via the Python C API. The macros even
import Python modules.  Well, I'm not the pygame packager.

> 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)."

Nothing I will address, because the Fedora multi-lib strategy is close to
undefined. Whether tools would create/update/maintain the white- and
black-lists or whether packages would be selected manually, is not
anything that is worked on officially and visibly.

> 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? :

No, since the new updates system is under development.
 
> 1) Blacklist by default Py* PY* py* perl* php* and probably others

Would be possible. Just needs somebody to come up with a list.

> 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

Core and Extras will be merged. Step 2) is not solved for Core yet
either, see e.g. broken updates for FC6: https://bugzilla.redhat.com/230194
Doing it in an automated way would need a lot of work (and most likely
would benefit from the package db), because it would also need to be
possible for entire i386 dep-chains to be withdrawn from the x86_64 repo
when an update breaks the chain.

> 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.

The issues with the main package are more important anyway. ;)