Agenda for the 2009-05-26 Packaging Committee meeting

[Panu Matilainen]

On Wed, 27 May 2009, Seth Vidal wrote:
>
> On Wed, 27 May 2009, Tom \"spot\" Callaway wrote:
>
>> On 05/27/2009 03:07 PM, Seth Vidal wrote:
>>> but I'm sure we'll muddle through - provided this is included in
>>> upstream rpm.
>> 
>> I think the key here is that we're waiting to deal with this particular
>> dilemma when upstream rpm has this functionality set.
>> 
>
> and the last time I asked - the current patches for this feature for rpm were 
> from suse's rpm and they were not liked, at all, by other rpm.org devs.

Apart from some mostly cosmetical issues, the problem with the soft 
dependency patches of Suse (which Mandriva uses too) is not so much what 
they do, but what they dont do. I've been on the verge of committing the 
patches several times and got stuck in the semantics swamp as many times. 
The Suse patches only define "rpm doesn't care" semantics, leaving 
everything to upper layers. Which seems kinda ok at first sight, but on a 
closer look I always end up with "but rpm does need to know, to some 
extent at least."

Take for example package A with
Requires(post): C
Recommends(post): B

What does that mean? Probably the %post script of A does something extra 
if B is present at that time, otherwise it wouldn't have such a dependency 
(one possible example of this could be mkinitrd). So at the very least 
ordering code in rpm should know about the soft dependencies, at which 
point rpm needs to have means to work with soft dependency sets too.

Or consider "Recommends: B >= 1.2" - what exactly does this mean? The 
package does something "better" if B is installed too, but what if we only 
have B 1.0 installed/available. Does the package even work with B 1.0? If 
it doesn't work with B 1.0, should rpm emit an error in such a case? If 
the version doesn't match, should B be pulled in anyway?

Or like you pointed out, what if a soft dependency conflicts with 
something. That something might even be pulled in due to other soft 
dependencies. Or hard dependencies of a soft dependency are 
unresolvable, is it an error or just quietly ignore the entire soft 
dep. Etc.

And that's just one side of it, the other half (Enhances) introduces a 
whole new dependency type: reverse dependencies (ie a package can claim 
another package to depend on itself) which is unlike anything rpm 
currently knows about. What makes it even more of an oddball is that there 
are no hard reverse dependencies, only soft ones. Reverse (soft or not) 
dependencies would be useful in a number of cases for third party 
repositories and such but they're also quite controversial and 
"dangerous" if abused.

 	- Panu -