[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Agenda for the 2009-05-26 Packaging Committee meeting



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 -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]