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

Smart-Matching Version Dependencies


I had planned to submit this to the debian-devel list, but I think it
should be discussed within our group first:


Currently according to policy there are five relationships that
package versions can have:
<< -- less than
< (deprecated) or <= -- less than or equal
= -- equal
> (deprecated) or >= -- greater than or equal
>> -- greater than

I would propose another dependency relationship, which would be denoted by:
~ or ~~ -- approximately equal

What is meant by approximate equality? Let me explain with an example...

Precedents and nice things this sort of syntax could help eliminate:
currently, the pkg-perl team maintains a module called Moose. It's an
object framework that requires another module, Class::MOP, to provide
metaobject programming features to Perl. They are closely related, and
generally whenever a release of either happens, both modules need to
be upgraded simultaneously. Class::MOP can be used on its own, but new
features in Moose often require something to be changed in Class::MOP,
so that new Moose module now requires the new Class::MOP.

All of this is a long-winded way to say that those modules basically
just need to be upgraded in step. We ensure that this happens by using
the following dependency relationships:

>From libmoose-perl [version 0.87] -- Depends: libclass-mop-perl (>= 0.89)
>From libclass-mop-perl [version 0.89] -- Breaks: libmoose-perl (<< 0.82+)

(As an aside, I think I actually screwed up the Breaks dependency on
libclass-mop-perl, as it probably breaks any version of Moose prior to
0.87. To my knowledge this hasn't screwed anything up yet, but such a
smart match feature could help in the future.)

Incidentally, the 0.82+ version number (note the trailing +) is to
cover the case where you've got Debian patch levels, like 0.82-2,
which would be considered newer than 0.82, yet is still broken.
Perhaps it would be useful to be able to say:

Depends: libclass-mop-perl (~ 0.89) -- which should mean "depends on
the upstream version 0.89 of libclass-mop-perl, but breaks on anything
older or newer." Then we could eliminate the second Breaks thing in

Some problems I can think of:

1. I'm not sure how often this really happens upstream. This is really
the only Perl module I can think of that does this, so I suppose it's
a bit of a corner case (and thus not worth codifying into Policy or

2. Just because something strictly depends on libclass-mop-perl
/approx/ 0.89 doesn't mean it won't work with 0.90. Presumably this
additional checking is useful for Breaks.

On the other hand, I want to make sure that mistakes caused by
forgetting to update either Depends or Breaks doesn't totally mess
things up...

Reply to: