Re: compound depends

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Oct 24, 2011 at 10:24:25PM +0900, OBATA Akio wrote:
> On Mon, 24 Oct 2011 19:37:55 +0900, David Holland 
> <dholland-pkgtech%netbsd.org@localhost> wrote:
> 
> >1) is that depends entry supposed to work the way it is, or should it
> >be split up, as per the following patch?
> 
> It should not be split out.

I'm not sure I agree here - I've always thought the compound way is
difficult to parse (from a human pov) - we are used to seeing single
a single in equality, not two. And I'd prefer to keep the individual
inequalities as simple as possible, in general.
 
> >2) is there a canonical reference for the syntax of depends entries?
> 
> PACKAGE WILDCARDS in pkg_info(1).

That describes the basic functionality of the way pkg_info(1) matches
elements of the inequality; it does not really describe the compound
inequality itself.

> How about following?
> 
> Index: mk/pkgformat/pkg/reduce-depends.awk
> ===================================================================
> RCS file: /cvsroot/pkgsrc/mk/pkgformat/pkg/reduce-depends.awk,v
> retrieving revision 1.1
> diff -u -r1.1 reduce-depends.awk
> --- mk/pkgformat/pkg/reduce-depends.awk 15 Oct 2011 00:23:09 -0000      1.1
> +++ mk/pkgformat/pkg/reduce-depends.awk 24 Oct 2011 13:22:26 -0000
> @@ -116,7 +116,7 @@
>                 for (d = 1; d <= D; d++) {
>                         dep = depends[pkgpath, d]
>                         if (dep ~ /[{]/ || \
> -                           dep ~ />=[0-9][0-9\.]*<[0-9]+/ || \
> +                           dep ~ />=[0-9][0-9\.]*(nb[0-9]+)?<[0-9]+/ || \
>                             dep !~ />=[0-9]+/)
>                         {
>                                 reduced[N++] = dep ":" pkgsrcdirs[pkgpath]

Looks great to me, but can we have an optional '=' in the second
inequality, please?  It costs little in such a complicated regexp, and
gives us the ability to match up to and including.  I doubt it will be
used much, but it sure would be nice not to be bitten by this at a
later date.

Thanks,
Alistair