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

Nagy Gabor ngaba at bibl.u-szeged.hu
Wed Dec 19 12:58:04 EST 2007


> On Dec 19, 2007 10:48 AM, Travis Willard <travis at archlinux.org> wrote:
> > On Dec 19, 2007 11:39 AM, Aaron Griffin <aaronmgriffin at gmail.com>
> > wrote:
> > >
> > > On Dec 19, 2007 10:11 AM, Travis Willard <travis at archlinux.org>
> > > 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




More information about the pacman-dev mailing list