broken deps outside of packagers control
Hans de Goede
j.w.r.degoede at hhs.nl
Fri Apr 20 07:13:27 UTC 2007
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
More information about the Fedora-maintainers
mailing list