Michael Schwendt wrote:
On Thu, 19 Apr 2007 22:36:10 +0200, Hans de Goede wrote:
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...
See reply below.
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.
So you do agree with me this is a problem? Remember this whole discussion
started because of you saying that the fix for broken deps, caused by the
current not smart multilib strategy, was to just remove the -devel sub packages
or kludge around otherwise. Now if you agree (in the light of examples like
pygtkglext and pygame) that just removing -devel packages or doing further
split ups is not the way to go, then we can start talking about a real solution.
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.
Well, I've given a start, all we really need todo is take a look at which
programming languages we ship, how bindings for those languages are named, and
then per language decide whether or not to include both versions of -devel
packages of them in multilib archs.
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
