Subject: Re: Dependency pattern syntax
To: None <>
From: None <>
List: tech-pkg
Date: 05/26/2006 10:53:08
On Fri, May 26, 2006 at 09:26:28AM +0200, Hubert Feyrer wrote:
> On Fri, 26 May 2006 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 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?
(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.