| 1 |
On Sat, 22 Sep 2012 10:05:41 -0700 |
| 2 |
Brian Dolbec <dolsen@g.o> wrote: |
| 3 |
|
| 4 |
> On Sat, 2012-09-22 at 09:55 +0200, Michał Górny wrote: |
| 5 |
> > Hello, |
| 6 |
> > |
| 7 |
> > The current dependency syntax: |
| 8 |
> > |
| 9 |
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION] |
| 10 |
> > |
| 11 |
> > suffers a few problems: |
| 12 |
> > |
| 13 |
> > |
| 14 |
> > 1. It is not really human-friendly. |
| 15 |
> > |
| 16 |
> > People don't say things like: |
| 17 |
> > |
| 18 |
> > I need newer than monkey-1.2. |
| 19 |
> > |
| 20 |
> > They say instead: |
| 21 |
> > |
| 22 |
> > I need monkey, newer than version 1.2. |
| 23 |
> > |
| 24 |
> [snip :/ ] |
| 25 |
> |
| 26 |
> > 4. It follows the syntax used by bash (for conditionals), pkg-config |
| 27 |
> > -- it is more natural in the environment. |
| 28 |
> > |
| 29 |
> |
| 30 |
> The BIG problem with that is bash has nothing to do with evaluating |
| 31 |
> dependencies. All bash does is source the *DEPEND and pass the value |
| 32 |
> to the package manager which does all the processing. And all 3 |
| 33 |
> current package managers are set up to parse those dep strings with a |
| 34 |
> set syntax and whitespace. None of the PM's dependency resolvers are |
| 35 |
> written in bash, two are python based, one C++. This proposal would |
| 36 |
> throw a big monkey wrench into parsing those strings. Introducing |
| 37 |
> lots of bugs, both in the PM and the ebuilds. |
| 38 |
|
| 39 |
It has all to do with people writing ebuilds. |
| 40 |
|
| 41 |
Also, I don't really see a problem with parsing it. Bash is not really |
| 42 |
relevant here; Python and C++ doesn't have a problem with either |
| 43 |
syntax. It's just about correct tokenizer design. |
| 44 |
|
| 45 |
> And this after all the fuss about the unified DEPENDENCIES proposal, |
| 46 |
> which is a small syntax change for the current processing code, easily |
| 47 |
> incorporated into the PM's. |
| 48 |
|
| 49 |
Err, no, it isn't. It requires redesigning ebuilds, cache, and probably |
| 50 |
a lot of code paths in the dependency parser unless the new syntax is |
| 51 |
going to be converted back to old one. |
| 52 |
|
| 53 |
Mine is easily incorporated into the PM; it is just a change |
| 54 |
in a single place splitting and parsing the tokens. |
| 55 |
|
| 56 |
> AND has definite, measurable advantages. |
| 57 |
|
| 58 |
We still didn't get a single one. |
| 59 |
|
| 60 |
So, I think you just don't like it and are inventing disadvantages |
| 61 |
without even caring enough to consider them before writing. |
| 62 |
|
| 63 |
-- |
| 64 |
Best regards, |
| 65 |
Michał Górny |
Archives