[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] A more natural (human-friendly) syntax for dependencies
From:       Michał Górny <mgorny () gentoo ! org>
Date:       2012-09-22 17:19:09
Message-ID: 20120922191909.1457a834 () pomiocik ! lan
[Download RAW message or body]


On Sat, 22 Sep 2012 10:05:41 -0700
Brian Dolbec <dolsen@gentoo.org> wrote:

> On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote:
> > Hello,
> > 
> > The current dependency syntax:
> > 
> >   [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> > 
> > suffers a few problems:
> > 
> > 
> > 1. It is not really human-friendly.
> > 
> > People don't say things like:
> > 
> >   I need newer than monkey-1.2.
> > 
> > They say instead:
> > 
> >   I need monkey, newer than version 1.2.
> > 
> [snip :/ ]
> 
> > 4. It follows the syntax used by bash (for conditionals), pkg-config
> > -- it is more natural in the environment.
> > 
> 
> The BIG problem with that is bash has nothing to do with evaluating
> dependencies.  All bash does is source the *DEPEND and pass the value
> to the package manager which does all the processing.  And all 3
> current package managers are set up to parse those dep strings with a
> set syntax and whitespace. None of the PM's dependency resolvers are
> written in bash, two are python based, one C++. This proposal would
> throw a big monkey wrench into parsing those strings.  Introducing
> lots of bugs, both in the PM and the ebuilds.

It has all to do with people writing ebuilds.

Also, I don't really see a problem with parsing it. Bash is not really
relevant here; Python and C++ doesn't have a problem with either
syntax. It's just about correct tokenizer design.

> And this after all the fuss about the unified DEPENDENCIES proposal,
> which is a small syntax change for the current processing code, easily
> incorporated into the PM's.

Err, no, it isn't. It requires redesigning ebuilds, cache, and probably
a lot of code paths in the dependency parser unless the new syntax is
going to be converted back to old one.

Mine is easily incorporated into the PM; it is just a change
in a single place splitting and parsing the tokens.

> AND has definite, measurable advantages. 

We still didn't get a single one.

So, I think you just don't like it and are inventing disadvantages
without even caring enough to consider them before writing.

-- 
Best regards,
Michał Górny

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]