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