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

[Dan McGee]

On Dec 19, 2007 11:58 AM, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
>
> > 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.

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