[opensuse-packaging] advanced requirements
Hi, I've got a problem I'm not sure how to solve with RPM dependencies. The following scenario: package A------ package C package B------ Package C supplements package A and B Packages A and B are independent Packages A and B must not have hard requirements to C Now the harder part: If package C is to be installed its version must match a certain feature provided by A and B. Actually I'm speaking about an API version. So A and C have to match as well as B and C. For people wanting to look at a real life example: I'm talking about mozilla-xulrunner191 and mozilla-xulrunner191-kde4. There already are supplements, requires and provides as needed to match two packages (A and C) but now a new package B comes into the game. I'm really confused already about it. Any hints? Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Just have A and B have an explict Provides on the api-version capability Provides: xulrunner-api-version = 1.2.3 Of course, name the capability (xulrunner-api-version) to be whatever the api is actually specifying, just make sure the name doesn't collide with an already used name for an rpm or other capability. and have C Requires: xulrunner-api-verison = 1.2.3 That will make C require exactly that version of the api. On Thu, 2009-12-03 at 10:48 -0600, Wolfgang Rosenauer wrote:
Hi,
I've got a problem I'm not sure how to solve with RPM dependencies.
The following scenario:
package A------ package C package B------
Package C supplements package A and B Packages A and B are independent Packages A and B must not have hard requirements to C
Now the harder part: If package C is to be installed its version must match a certain feature provided by A and B. Actually I'm speaking about an API version. So A and C have to match as well as B and C.
For people wanting to look at a real life example: I'm talking about mozilla-xulrunner191 and mozilla-xulrunner191-kde4. There already are supplements, requires and provides as needed to match two packages (A and C) but now a new package B comes into the game.
I'm really confused already about it.
Any hints?
Wolfgang
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 3 Dec 2009, Luke Imhoff wrote:
Just have A and B have an explict Provides on the api-version capability
Provides: xulrunner-api-version = 1.2.3
Of course, name the capability (xulrunner-api-version) to be whatever the api is actually specifying, just make sure the name doesn't collide with an already used name for an rpm or other capability.
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That would allow to install a B that doesn't provide this capability, as long as A does. You need to use different names for A and B and require both from C (in addition to the supplements it already has). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am 03.12.2009 18:03, schrieb Michael Matz:
Hi,
On Thu, 3 Dec 2009, Luke Imhoff wrote:
Just have A and B have an explict Provides on the api-version capability
Provides: xulrunner-api-version = 1.2.3
Of course, name the capability (xulrunner-api-version) to be whatever the api is actually specifying, just make sure the name doesn't collide with an already used name for an rpm or other capability.
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That would allow to install a B that doesn't provide this capability, as long as A does. You need to use different names for A and B and require both from C (in addition to the supplements it already has).
But then I would for example get a hard requirement to B when A and C are installed and that's also not wanted ;-) Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 3 Dec 2009, Wolfgang Rosenauer wrote:
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That would allow to install a B that doesn't provide this capability, as long as A does. You need to use different names for A and B and require both from C (in addition to the supplements it already has).
But then I would for example get a hard requirement to B when A and C are installed and that's also not wanted ;-)
Then you didn't specify your requirements exactly: I understood your first mail as C supplementing (A and B), as in, C should be there, if available and A _and_ B are installed (in difference to e.g. just B installed). So what exactly do you need? C installed if either A xor B (or both) installed, but in a minimum version? In a way that A is independend of B, but if both are installed then one of them is the "newest" one as far as C in concerned? Or rather that if both are installed then both need to provide at least version X of whatever, but apart from that (especially in absence of C) there should be no conflict of A<->B no matter what version they provide? In that case you need to model C like a patch: it needs to conflict with all smaller versions of $provides. This only works if A and B provide something at all. E.g.: A: Provides: provides-for-C = 1.0 B: Provides: provides-for-C = 1.1 C: Conflicts: provides-for-C < 1.0 (plus the supplement that C already has). In this way it will be possible to install A and C alone, or A and B and C. But it will not be possible to install an old A and C (if the predicates in the solver are solved correctly), e.g. when A only provides "provides-for-C = 0.2". Problems will arise if A or B don't provide "provides-for-C" at all: the missing caps won't generate a conflict, hence very old A's could be installed. I think you need to solved this by an additional conflict from C to old versions of A and B which you need to hardcode. E.g. assuming that package A in version 1.3 was the first to provide provides-for-C at all you would add a conflict: C: Conflicts: A < 1.3 to C. From then on you would not be able to install too old A/B's (those that don't give any hint) anymore at all, and from then on only newer A/B's that match the requirements of C, if installed. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 12/03/2009 10:00 PM, Michael Matz wrote:
Hi,
On Thu, 3 Dec 2009, Wolfgang Rosenauer wrote:
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That would allow to install a B that doesn't provide this capability, as long as A does. You need to use different names for A and B and require both from C (in addition to the supplements it already has).
But then I would for example get a hard requirement to B when A and C are installed and that's also not wanted ;-)
Then you didn't specify your requirements exactly: I understood your first mail as C supplementing (A and B), as in, C should be there, if available and A _and_ B are installed (in difference to e.g. just B installed).
Yeah, I probably failed a bit with describing the issue. C supplements A; and C supplements B (together with some other package but that's not that important)
Or rather that if both are installed then both need to provide at least version X of whatever, but apart from that (especially in absence of C) there should be no conflict of A<->B no matter what version they provide?
Correct.
In that case you need to model C like a patch: it needs to conflict with all smaller versions of $provides. This only works if A and B provide something at all. E.g.:
A: Provides: provides-for-C = 1.0 B: Provides: provides-for-C = 1.1
C: Conflicts: provides-for-C < 1.0
(plus the supplement that C already has). In this way it will be possible to install A and C alone, or A and B and C. But it will not be possible to install an old A and C (if the predicates in the solver are solved correctly), e.g. when A only provides "provides-for-C = 0.2". Problems will arise if A or B don't provide "provides-for-C" at all: the missing caps won't generate a conflict, hence very old A's could be installed. I think you need to solved this by an additional conflict from C to old versions of A and B which you need to hardcode. E.g. assuming that package A in version 1.3 was the first to provide provides-for-C at all you would add a conflict:
Very old A's or B's (as in when they don't have provides-for-C) don't need to conflict. It still works but w/o a certain feature.
C: Conflicts: A < 1.3
to C. From then on you would not be able to install too old A/B's (those that don't give any hint) anymore at all, and from then on only newer A/B's that match the requirements of C, if installed.
I think the conflicts to older versions of the virtual provides (provides-for-C) as suggested by Luke and darix should work. Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am 03.12.2009 17:59, schrieb Luke Imhoff:
Just have A and B have an explict Provides on the api-version capability
Provides: xulrunner-api-version = 1.2.3
Of course, name the capability (xulrunner-api-version) to be whatever the api is actually specifying, just make sure the name doesn't collide with an already used name for an rpm or other capability.
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That was my first idea or in fact is what is already implemented. That's not sufficient to what I want to achieve because: A and B might not have the same api-version provides at any point in time and in that case C shouldn't be updated until A _and_ B provide the matching api version. Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 2009-12-03 at 11:19 -0600, Wolfgang Rosenauer wrote:
Am 03.12.2009 17:59, schrieb Luke Imhoff:
Just have A and B have an explict Provides on the api-version capability
Provides: xulrunner-api-version = 1.2.3
Of course, name the capability (xulrunner-api-version) to be whatever the api is actually specifying, just make sure the name doesn't collide with an already used name for an rpm or other capability.
and have C Requires: xulrunner-api-verison = 1.2.3
That will make C require exactly that version of the api.
That was my first idea or in fact is what is already implemented. That's not sufficient to what I want to achieve because:
A and B might not have the same api-version provides at any point in time and in that case C shouldn't be updated until A _and_ B provide the matching api version.
Wolfgang
Then just add Conflicts: xulrunner-api-version != 1.2.3 in C. The other option is to have A and B conflict with each other if they don't supply the same api-version. It depends if only C needs the same version or if A and B need the same version too. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2009-12-03 11:33:05 -0600, Luke Imhoff wrote:
Then just add Conflicts: xulrunner-api-version != 1.2.3 in C. The other option is to have A and B conflict with each other if they don't supply the same api-version. It depends if only C needs the same version or if A and B need the same version too.
luke, almost correct. but i would use "<" instead of "!=". in *-kde4: Requires: mozilla-kde4-version = %{helper_version} # make sure the package is not installed when there is still # a user of the old api version Conflicts: mozilla-kde4-version < %{helper_version} -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 2009-12-03 at 12:09 -0600, Marcus Rueckert wrote:
On 2009-12-03 11:33:05 -0600, Luke Imhoff wrote:
Then just add Conflicts: xulrunner-api-version != 1.2.3 in C. The other option is to have A and B conflict with each other if they don't supply the same api-version. It depends if only C needs the same version or if A and B need the same version too.
luke, almost correct. but i would use "<" instead of "!=". in *-kde4:
Requires: mozilla-kde4-version = %{helper_version} # make sure the package is not installed when there is still # a user of the old api version Conflicts: mozilla-kde4-version < %{helper_version}
The < only works if all apis are backwards compatible. It was implied that the api was neither forward nor backwards compatible, which is why I said !=.
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2009-12-03 12:18:54 -0600, Luke Imhoff wrote:
Requires: mozilla-kde4-version = %{helper_version} # make sure the package is not installed when there is still # a user of the old api version Conflicts: mozilla-kde4-version < %{helper_version}
The < only works if all apis are backwards compatible. It was implied that the api was neither forward nor backwards compatible, which is why I said !=.
huh? the requires makes sure that the exact version is required. the conflicts makes sure that nothing happens as long a single package still provides mozilla-kde4-version smaller than the required version. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (4)
-
Luke Imhoff -
Marcus Rueckert -
Michael Matz -
Wolfgang Rosenauer