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