[pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

newer
[pacman-dev] [GIT] The official...

older
[pacman-dev] [GIT] The official...

Nagy Gabor

18 Dec 2007 18 Dec '07

1:26 p.m.

From c0d82c952dd7fc59cdc478898025a21d9ecf03d6 Mon Sep 17 00:00:00 2001 From: Nagy Gabor Date: Tue, 18 Dec 2007 14:24:44 +0100 Subject: [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added You can use foo<2.0 and foo>2.0 as depend add046.py and add047.py pactests were added to check this Signed-off-by: Nagy Gabor --- lib/libalpm/alpm.h | 4 +++- lib/libalpm/deps.c | 19 ++++++++++++++++++- pactest/tests/add046.py | 14 ++++++++++++++ pactest/tests/add047.py | 14 ++++++++++++++ 4 files changed, 49 insertions(+), 2 deletions(-) create mode 100644 pactest/tests/add046.py create mode 100644 pactest/tests/add047.py diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index f64796c..3a484be 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -369,7 +369,9 @@ typedef enum _pmdepmod_t { PM_DEP_MOD_ANY = 1, PM_DEP_MOD_EQ, PM_DEP_MOD_GE, - PM_DEP_MOD_LE + PM_DEP_MOD_LE, + PM_DEP_MOD_GT, + PM_DEP_MOD_LT } pmdepmod_t; pmdepend_t *alpm_splitdep(const char *depstring); diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 1603f99..8d77fd4 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -310,6 +310,8 @@ static int dep_vercmp(const char *version1, pmdepmod_t mod, case PM_DEP_MOD_EQ: equal = (cmp == 0); break; case PM_DEP_MOD_GE: equal = (cmp >= 0); break; case PM_DEP_MOD_LE: equal = (cmp <= 0); break; + case PM_DEP_MOD_LT: equal = (cmp < 0); break; + case PM_DEP_MOD_GT: equal = (cmp > 0); break; default: equal = 1; break; } } @@ -374,10 +376,19 @@ pmdepend_t SYMEXPORT *alpm_splitdep(const char *depstring) depend->mod = PM_DEP_MOD_LE; *ptr = '\0'; ptr += 2; - } else if((ptr = strstr(newstr, "="))) { + } else if((ptr = strstr(newstr, "="))) { /* Note: we must do =,<,> checks after <=, >= checks */ depend->mod = PM_DEP_MOD_EQ; *ptr = '\0'; ptr += 1; + } else if((ptr = strstr(newstr, "<"))) { + depend->mod = PM_DEP_MOD_LT; + *ptr = '\0'; + ptr += 1; + } else if((ptr = strstr(newstr, ">"))) { + depend->mod = PM_DEP_MOD_GT; + *ptr = '\0'; + ptr += 1; + } else { /* no version specified - copy in the name and return it */ depend->mod = PM_DEP_MOD_ANY; @@ -684,6 +695,12 @@ char SYMEXPORT *alpm_dep_get_string(const pmdepend_t *dep) case PM_DEP_MOD_EQ: opr = "="; break; + case PM_DEP_MOD_LT: + opr = "<"; + break; + case PM_DEP_MOD_GT: + opr = ">"; + break; default: opr = ""; break; diff --git a/pactest/tests/add046.py b/pactest/tests/add046.py new file mode 100644 index 0000000..5f967cb --- /dev/null +++ b/pactest/tests/add046.py @@ -0,0 +1,14 @@ +self.description = "pkg2<2.0 dependency (satisfy)" + +p = pmpkg("pkg1") +p.depends = ["pkg2<2.0"] +self.addpkg(p) + +lp = pmpkg("pkg2", "1.9b-3") +self.addpkg2db("local", lp) + +self.args = "-A %s" % p.filename() + +self.addrule("PACMAN_RETCODE=0") +self.addrule("PKG_EXIST=pkg1") +self.addrule("PKG_EXIST=pkg2") diff --git a/pactest/tests/add047.py b/pactest/tests/add047.py new file mode 100644 index 0000000..153364a --- /dev/null +++ b/pactest/tests/add047.py @@ -0,0 +1,14 @@ +self.description = "pkg2<2.0 dependency (not satisfy)" + +p = pmpkg("pkg1") +p.depends = ["pkg2<2.0"] +self.addpkg(p) + +lp = pmpkg("pkg2", "2.0-3") +self.addpkg2db("local", lp) + +self.args = "-A %s" % p.filename() + +self.addrule("PACMAN_RETCODE=1") +self.addrule("!PKG_EXIST=pkg1") +self.addrule("PKG_EXIST=pkg2") -- 1.5.3.7

Show replies by date

Dan McGee

18 Dec 18 Dec

3:57 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 18, 2007 7:26 AM, Nagy Gabor wrote:

...

...
From c0d82c952dd7fc59cdc478898025a21d9ecf03d6 Mon Sep 17 00:00:00 2001 From: Nagy Gabor Date: Tue, 18 Dec 2007 14:24:44 +0100 Subject: [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

You can use foo<2.0 and foo>2.0 as depend add046.py and add047.py pactests were added to check this

Signed-off-by: Nagy Gabor

Seems fine to me. Aaron, any objections? -Dan

Xavier

4:08 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Tue, Dec 18, 2007 at 09:57:53AM -0600, Dan McGee wrote:

...

On Dec 18, 2007 7:26 AM, Nagy Gabor wrote:

...
...
From c0d82c952dd7fc59cdc478898025a21d9ecf03d6 Mon Sep 17 00:00:00 2001 From: Nagy Gabor Date: Tue, 18 Dec 2007 14:24:44 +0100 Subject: [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

You can use foo<2.0 and foo>2.0 as depend add046.py and add047.py pactests were added to check this

Signed-off-by: Nagy Gabor

Seems fine to me. Aaron, any objections?

I'm not sure you missed this mail, but just in case : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010527.html I have to side with Aaron here, actually, I'm just going to quote what he said : "That said, if someone wants to add in support for > and < comparators, I wouldn't complain. It just sounds like "feature creep" to me - it's solving a problem no one encounters on a day to day basis." That is, I don't find it very useful either, but since it doesn't add much code, it's not a big deal.

Dan McGee

4:36 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 18, 2007 10:08 AM, Xavier wrote:

...

On Tue, Dec 18, 2007 at 09:57:53AM -0600, Dan McGee wrote:

...
On Dec 18, 2007 7:26 AM, Nagy Gabor wrote:

...
...
From c0d82c952dd7fc59cdc478898025a21d9ecf03d6 Mon Sep 17 00:00:00 2001 From: Nagy Gabor Date: Tue, 18 Dec 2007 14:24:44 +0100 Subject: [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

You can use foo<2.0 and foo>2.0 as depend add046.py and add047.py pactests were added to check this

Signed-off-by: Nagy Gabor

Seems fine to me. Aaron, any objections?

I'm not sure you missed this mail, but just in case : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010527.html

I have to side with Aaron here, actually, I'm just going to quote what he said : "That said, if someone wants to add in support for > and < comparators, I wouldn't complain. It just sounds like "feature creep" to me - it's solving a problem no one encounters on a day to day basis."

That is, I don't find it very useful either, but since it doesn't add much code, it's not a big deal.

Yeah, I saw the email. But it was followed through with a light and straightforward patch, so that is why I do not object to merging this (although I too do not see a wide range of use for this). -Dan

Aaron Griffin

4:38 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 18, 2007 10:36 AM, Dan McGee wrote:

...

On Dec 18, 2007 10:08 AM, Xavier wrote:

...
On Tue, Dec 18, 2007 at 09:57:53AM -0600, Dan McGee wrote:

...
On Dec 18, 2007 7:26 AM, Nagy Gabor wrote:

...
...
From c0d82c952dd7fc59cdc478898025a21d9ecf03d6 Mon Sep 17 00:00:00 2001 From: Nagy Gabor Date: Tue, 18 Dec 2007 14:24:44 +0100 Subject: [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

You can use foo<2.0 and foo>2.0 as depend add046.py and add047.py pactests were added to check this

Signed-off-by: Nagy Gabor

Seems fine to me. Aaron, any objections?

I'm not sure you missed this mail, but just in case : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010527.html

I have to side with Aaron here, actually, I'm just going to quote what he said : "That said, if someone wants to add in support for > and < comparators, I wouldn't complain. It just sounds like "feature creep" to me - it's solving a problem no one encounters on a day to day basis."

That is, I don't find it very useful either, but since it doesn't add much code, it's not a big deal.

Yeah, I saw the email. But it was followed through with a light and straightforward patch, so that is why I do not object to merging this (although I too do not see a wide range of use for this).

Yup, Nagy kicked ass here. This is great. Like I said, it MAY be a bit of feature creep, but the code is here and it's not all that much. /me gives a thumbs up

Nagy Gabor

19 Dec 19 Dec

7:24 a.m.

...

I'm not sure you missed this mail, but just in case : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010527.html

I have to side with Aaron here, actually, I'm just going to quote what he said : "That said, if someone wants to add in support for > and < comparators, I wouldn't complain. It just sounds like "feature creep" to me - it's solving a problem no one encounters on a day to day basis."

That is, I don't find it very useful either, but since it doesn't add much code, it's not a big deal.

Well, I agree, that this will be rarely used (mainly >). So if you can show me a clean way (not kernel26 provision) to say that "foo depends on kernel-2.6.x" I will revert this immediately (this was the only reason for implementing) Bye

Aaron Griffin

4:04 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 1:24 AM, Nagy Gabor wrote:

...

Well, I agree, that this will be rarely used (mainly >). So if you can show me a clean way (not kernel26 provision) to say that "foo depends on kernel-2.6.x" I will revert this immediately (this was the only reason for implementing)

I thought our version compartors already worked for this case? That is, for foo-1.2.3, doing a depends=(foo>=1.2) will work just fine

Travis Willard

4:11 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 11:04 AM, Aaron Griffin wrote:

...

On Dec 19, 2007 1:24 AM, Nagy Gabor wrote:

...
Well, I agree, that this will be rarely used (mainly >). So if you can show me a clean way (not kernel26 provision) to say that "foo depends on kernel-2.6.x" I will revert this immediately (this was the only reason for implementing)

I thought our version compartors already worked for this case? That is, for foo-1.2.3, doing a depends=(foo>=1.2) will work just fine

I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Aaron Griffin

4:39 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 10:11 AM, Travis Willard wrote:

...

On Dec 19, 2007 11:04 AM, Aaron Griffin wrote:

...
On Dec 19, 2007 1:24 AM, Nagy Gabor wrote:

...
Well, I agree, that this will be rarely used (mainly >). So if you can show me a clean way (not kernel26 provision) to say that "foo depends on kernel-2.6.x" I will revert this immediately (this was the only reason for implementing)

I thought our version compartors already worked for this case? That is, for foo-1.2.3, doing a depends=(foo>=1.2) will work just fine

I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Yeah, and I was under the impression that >=2.6.20 would match any of 2.6.20, 2.6.20.1, 2.6.20.7827233, 2.6.20-45, etc I can't verify right now, but I thought 2.6.20.x was always > 2.6.20 in libalpm

Travis Willard

4:48 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 11:39 AM, Aaron Griffin wrote:

...

On Dec 19, 2007 10:11 AM, Travis Willard wrote:

...
I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Yeah, and I was under the impression that >=2.6.20 would match any of 2.6.20, 2.6.20.1, 2.6.20.7827233, 2.6.20-45, etc

Lol - gmail highlighted 2.6.20.1 as a http:// link to an IP address. Oh, gmail. Yes, >=2.6.20 will match those, but it will match _MORE_ than those, which is the problem (in my mind) To match specifically 2.6.20.x, you need two entries in the depends: kernel26>=2.6.20 and kernel26<2.6.21 -- any module we build will not be compatible, for example, with the next-higher 2.6.x release, and if we can explicitly say which kernels are allowed in the module's dependencies, I think that's even better than an open-ended >=2.6.20 dep.

...

I can't verify right now, but I thought 2.6.20.x was always > 2.6.20 in libalpm

Dan McGee

4:57 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 10:48 AM, Travis Willard wrote:

...

On Dec 19, 2007 11:39 AM, Aaron Griffin wrote:

...
On Dec 19, 2007 10:11 AM, Travis Willard wrote:

...
I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Yeah, and I was under the impression that >=2.6.20 would match any of 2.6.20, 2.6.20.1, 2.6.20.7827233, 2.6.20-45, etc

Lol - gmail highlighted 2.6.20.1 as a http:// link to an IP address. Oh, gmail.

Yes, >=2.6.20 will match those, but it will match _MORE_ than those, which is the problem (in my mind)

To match specifically 2.6.20.x, you need two entries in the depends: kernel26>=2.6.20 and kernel26<2.6.21 -- any module we build will not be compatible, for example, with the next-higher 2.6.x release, and if we can explicitly say which kernels are allowed in the module's dependencies, I think that's even better than an open-ended >=2.6.20 dep.

Aha, this now makes a lot of sense. Do we have any pactests to ensure multiple depends on the same package will work? I think we should make some if we don't have them (one that is satisfied, one that is not). Something testing what would happen if you wanted to upgrade the kernel but could not upgrade because module deps were not satisfied would be cool. -Dan

Nagy Gabor

5:58 p.m.

...

On Dec 19, 2007 10:48 AM, Travis Willard wrote:

...
On Dec 19, 2007 11:39 AM, Aaron Griffin wrote:

...
On Dec 19, 2007 10:11 AM, Travis Willard wrote:

...
I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Yeah, and I was under the impression that >=2.6.20 would match any of 2.6.20, 2.6.20.1, 2.6.20.7827233, 2.6.20-45, etc

Lol - gmail highlighted 2.6.20.1 as a http:// link to an IP address. Oh, gmail.

Yes, >=2.6.20 will match those, but it will match _MORE_ than those, which is the problem (in my mind)

To match specifically 2.6.20.x, you need two entries in the depends: kernel26>=2.6.20 and kernel26<2.6.21 -- any module we build will not be compatible, for example, with the next-higher 2.6.x release, and if we can explicitly say which kernels are allowed in the module's dependencies, I think that's even better than an open-ended >=2.6.20 dep.

Aha, this now makes a lot of sense. Do we have any pactests to ensure multiple depends on the same package will work? I think we should make some if we don't have them (one that is satisfied, one that is not). Something testing what would happen if you wanted to upgrade the kernel but could not upgrade because module deps were not satisfied would be cool.

-Dan

Imho we don't need these pactests, because kernel26>=2.6.20 and kernel26<2.6.21 are two different dependencies (every line in %DEPENDS% is splited then checked with alpm_depcmp), even you can list the _same_ dependency 3 times, this is treated as 3 different dependencies everywhere in the code. I mention a really odd situation: You have a package with foo<2.0 AND foo>=1.0 dependency. If there is a foo 0.1-1 package installed (this satisfies foo<2.0) and a foo 3.0-1 (provision)package installed, both of our dependencies are satisfied but this is not what we wanted. <- I simply ignore this case, because this is really far from real life, but I had to mention this to be "precise". Bye

Dan McGee

6:16 p.m.

New subject: [pacman-dev] [PATCH] PM_DEP_MOD_LT and PM_DEP_MOD_GT depmods added

On Dec 19, 2007 11:58 AM, Nagy Gabor wrote:

...

...
On Dec 19, 2007 10:48 AM, Travis Willard wrote:

...
On Dec 19, 2007 11:39 AM, Aaron Griffin wrote:

...
On Dec 19, 2007 10:11 AM, Travis Willard wrote:

...
I think what he's getting at is he wants a dependency on kernel26 version 2.6.x for any x. Saying depends=(kernel26>=2.6) will match kernel26 for any version >= 2.6, which is not the same thing, because it will match versions 2.7, 2.8, 3.0, and 1000.

Yeah, and I was under the impression that >=2.6.20 would match any of 2.6.20, 2.6.20.1, 2.6.20.7827233, 2.6.20-45, etc

Lol - gmail highlighted 2.6.20.1 as a http:// link to an IP address. Oh, gmail.

Yes, >=2.6.20 will match those, but it will match _MORE_ than those, which is the problem (in my mind)

To match specifically 2.6.20.x, you need two entries in the depends: kernel26>=2.6.20 and kernel26<2.6.21 -- any module we build will not be compatible, for example, with the next-higher 2.6.x release, and if we can explicitly say which kernels are allowed in the module's dependencies, I think that's even better than an open-ended >=2.6.20 dep.

Aha, this now makes a lot of sense. Do we have any pactests to ensure multiple depends on the same package will work? I think we should make some if we don't have them (one that is satisfied, one that is not). Something testing what would happen if you wanted to upgrade the kernel but could not upgrade because module deps were not satisfied would be cool.

-Dan

Imho we don't need these pactests, because kernel26>=2.6.20 and kernel26<2.6.21 are two different dependencies (every line in %DEPENDS% is splited then checked with alpm_depcmp), even you can list the _same_ dependency 3 times, this is treated as 3 different dependencies everywhere in the code.

Yes, I am aware of this, but tests should not be written based on knowledge of what is in the black box- the idea is that if we change implementation, we still test what was the expected behavior and ensure it still stands. We need them not because they are currently failing, but because they will catch possible slipups in the future.

...

I mention a really odd situation: You have a package with foo<2.0 AND foo>=1.0 dependency. If there is a foo 0.1-1 package installed (this satisfies foo<2.0) and a foo 3.0-1 (provision)package installed, both of our dependencies are satisfied but this is not what we wanted. <- I simply ignore this case, because this is really far from real life, but I had to mention this to be "precise".

Ha, this is quite hard to trigger, so we can punt on this for now. :) Glad you mentioned it though. -Dan

5982

Age (days ago)

5983

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Aaron Griffin
Dan McGee
Nagy Gabor
Travis Willard
Xavier