comps discussion at fudcon and the future

Panu Matilainen pmatilai at laiskiainen.org
Fri Jan 16 07:48:37 UTC 2009


On Fri, 16 Jan 2009, Thorsten Leemhuis wrote:

> On 16.01.2009 07:34, Panu Matilainen wrote:
>> On Fri, 16 Jan 2009, Kevin Kofler wrote:
>>> seth vidal wrote:
>>> 
>>>> Really? Who is making the plans for soft deps. Doesn't seem like it at
>>>> the rpm layer.
>>> Last I checked it was on the rpm.org todo list. Maybe it got dropped. That
>>> would be unfortunate, because I think they could be useful, I've seen
>>> several cases where they would have helped (just one example: Kile (a 
>>> LaTeX
>>> editor) can call many tools, most users will want them dragged in, but 
>>> some
>>> don't and Kile will still work, with reduced functionality, without them -
>>> just grep for Requires(hint) in packages (mostly those touched by Rex
>>> Dieter) to see more places where we'd like soft dependencies) and Debian
>>> fans keep making fun of us because we don't have them ;-).
>> It hasn't been dropped, only post-poned until we figure out a bunch of 
>> details.
>
> I don't want to get tracked into the discussions if "Requires(hint)" and 
> other soft deps make sense to support in rpm/yum or not.
>
> But if conditionals really go away in comps it would be really nice for 
> external repos like RPM Fusion to have a alternative way to automatically get 
> (for example(¹) ) xine-lib-extras-freeworld installed if the users installs 
> (or already has installed) xine-lib.
>
> Something like that is afaics needed to make things "just work" (²) -- and 
> that's what we all want, isn't it?

Yup, I remember sorely missing the ability to do this in "former life".

This is the "enhances" use-case, which is why it typically gets bundled up 
with soft-dependencies. Only it's got relatively little to do with the 
elasticity of a dependency, this would be a reverse dependency (whether 
it's soft or not is another issue), which is a completely new dependency 
class and the reason "enhances" is such a platypus.

 	- Panu -




More information about the fedora-devel-list mailing list