On Fri, May 26, 2006 at 09:26:28AM +0200, Hubert Feyrer wrote:
> On Fri, 26 May 2006 joerg@britannica.bec.de wrote:
> >>How about
> >>	php>=4.4<4.5
> >>instead, which more precisely describes what is wanted?
> >
> >This works in this situation, but not sure if can be done in all cases.
> >E.g. php-4.4p1 would match your pattern, but not the fnmatch style.
> 
> About this whole proposal:
> I didn't really understand what the point of changing the complete syntax 
> for our version specifier is. If it's just to allow ranges, then maybe 
> that could be done within the current scheme, instead of changing 
> everything and its mother.

The reasons for this are many fold:
(a) The current syntax and implementation is ridicilous complex and the
implementation has a number of documented insanities. E.g. foo<2>3
doesn't really give what one would expect.
(b) The current use depends on a number of side effects of the
implementation, e.g. the order in which dependencies are processed.
This is somewhat hidden by the reduce-depends.mk logic, which is
incomplete as well though. For example, the php handling depends on
php-4.4.* being evaluated before php>=4.4.1nb3.
(c) Even worse than (b), alternative patterns can result in relatively
arbitrary resolution. Quick, which packages get selected by the
following rule under which circumstances?
{ghostscript,ghostscript-afpl,ghostscript-esp,ghostscript-gnu}>=6.01
(d) The syntax proposed is a superset of the current Dewey syntax with
the intention of being convertable to from the three other rules we have
in pmatch.

> That said:
> May I suggest that this be deferred for now, and be part of some re-design 
> of the pkg_install tools'n'stuff that's gonna happen for Summer-of-Code?

The reason I started this now are:
(a) It wasn't sure in which form the project would happen (Hi Hubert
    :-) )
(b) It is relatively isolated and helps *current* users as well. My
intention was to implement the matcher and extend the current
pkg_install to use it by default and fallback to the "old" mechanisms if
a pattern is rejected as error.
(c) The problems I'm hitting (e.g. multiple alternatives) are
problematic for my other project, the better bulk build.

Joerg