rpm 4.12 and weak dependencies

Ralf Corsepius rc040203 at freenet.de
Thu Oct 9 06:57:42 UTC 2014

On 10/09/2014 08:41 AM, Petr Spacek wrote:
> On 8.10.2014 23:04, Haïkel wrote:
>> 2014-10-08 20:31 GMT+02:00 Kevin Fenzi <kevin at scrye.com>:
>>> Greetings.
>>> This F21 change:
>>> http://fedoraproject.org//wiki/Changes/RPM-4.12
>>> has brought us 'weak dependencies', namely:
>>> Recommends, Suggests, Supplements and Enhances
>>> Rpm in f21 and rawhide sees these in spec files and builds fine with
>>> them. createrepo in those branches also exports this into the metadata.
>>> yum however doesn't do anything with that information.
>>> dnf does (although it's not clear to me what exactly it does do, so
>>> input from dnf maintainers would be great).
>>> There's 4 packages that are already using these weak deps, but our
>>> default package manager (yum) doesn't understand them. People
>>> installing via yum and installing via dnf will see different behavior.
>>> I filed a fesco ticket to ask that we ask maintainers to please not add
>>> these until we have guidelines and our default package manager supports
>>> this information:  https://fedorahosted.org/fesco/ticket/1353
>>> FESCo asked me to post here and see what folks think.
>>> Should we just ask folks not to use these for now (honor system).
>>> Should we add a check to redhat-rpm-macros to check packages and fail
>>> the build if they use these tags (for now).
>>> Should we just not care that people will see different behavior and
>>> leave it up to maintainers?
>>> Or should we do something else?
>> Since our default package manager does not understand them, it's
>> harmless to leave it up to the maintainers.
>> Most importantly, we need to update packaging guidelines to explain
>> what are the semantic differences between these different tags. But
>> that's a minor update.
>> Before dnf gets promoted as the default package manager, it would be
>> interesting to do some widespread testing.
>> 1. document dnf behavior with weak dependencies and related
>> configuration options
>> 2. let people experiment and provide feedbacks
>> 3. based on feedbacks either propose guidelines or status quo if
>> that's ok
> I agree with Haïkel.
I do not.

> Why should we ban weak dependencies if they really
> do nothing in YUM?

We need a precise and detailed functional description about what these 
"weak dependencies" are supposed to do.

Also, we would need a precise and detailed description of how weak deps 
are seen by non-weak-deps aware programs.

Otherwise chaos is pre-programmed.


More information about the devel mailing list