Subject: Re: Dependency pattern syntax
To: None <tech-pkg@netbsd.org>
From: Johnny C. Lam <jlam@pkgsrc.org>
List: tech-pkg
Date: 05/29/2006 19:31:31
On Wed, May 24, 2006 at 11:47:47PM +0200, joerg@britannica.bec.de wrote:
> 
> We currently have:
> (a) fnmatch syntax (php-4.4.*, zip-[0-9]*)
> (b) csh like patterns (foo-1.2{,nb*} being popular, but also e.g.
>     {ghostscript,ghostscript-afpl}>=6.01)
> (c) Dewey patterns (pkg>=1.4, pkg>=1.4<2)
> 
> Frankly, this is a total mess to implement and esp. the former too
> provide too much flexibility for this purpose.

Yes, I completely agree.  It's a mix of textual matching (a & b) and
real version semantics (c), which requires two different levels of
completely different types of parsing to understand any dependency
pattern.  This is bad.

[snip]
> To illustrate this a translation of the patterns above:
> 	php-4.4.* => php~4.4
> 	zip-[0-9]* => zip
> 	foo-1.2{,nb*} => foo~1.2nb
> 		(note: missing nb part treated as 0, foo-1.2.1 would *not* match)
> 	{ghostscript,ghostscript-afpl}>=6.01
> 	  => ghostscript>=6.01|ghostscript-afpl>=6.01
> 	pkg>=1.4
> 	pkg>=1.4<2

I think this is very natural and concise.

To clarify something for other readers of this thread, the use of "|"
to describe multiple packages that can satisfy a dependency is good
because it let allows for a clean way to search a package repository
for a matching package -- we try the different "branches" of the "|"
expression in order to find a matching package.

There was some question as to whether the ~ operator is necessary,
since it appears that, e.g. php~4.4 can be replaced with php>=4.4<4.5.
However, I find that the latter is a messy way to say, e.g. "php
versions along *this* release branch", because it requires that we
invent an upper bound, whereas, e.g. php~4.4, is a simple way of saying
exactly that.

> I think all uses of (a) and (b) in the tree can be converted, but I
> haven't checked the list yet. What do you think?

I think this is a very big improvement to the dependency patterm syntax
-- it removes ambiguity and is also simpler to parse without losing
the expressive power we need to describe dependencies.

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>