On Sat, 22 Sep 2012 12:07:38 +0300
Alex Alexander <wired@gentoo.org> wrote:

> On Sep 22, 2012 10:58 AM, "Michał Górny" <mgorny@gentoo.org> wrote:
> >
> > Hello,
> >
> > The current dependency syntax:
> >
> > [VERSION-OP] PACKAGE-NAME ["-" PACKAGE-VERSION]
> >
> > suffers a few problems:
>
> The syntax you are describing is used all over portage, not just
> dependencies. Some examples are the /etc/portage/package.* files,
> has_version or exact version matching when emerging.

Yes, having it in all cases would be good.

--
Best regards,
Michał Górny

On 23 September 2012 00:13, Luca Barbato <lu_zero@gentoo.org> wrote:
> Please try not fix/break what is not broken.

+1

--
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

On 22/09/2012 09:35, Ben de Groot wrote:
>> > Please try not fix/break what is not broken.
> +1

Same here.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

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.

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. AND has definite, measurable advantages.

so, -1
--
Brian Dolbec <dolsen@gentoo.org>

On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:

>

> emerge 'foo >= 1.1' 'bar < 1.0'?

> emerge foo '>=' 1.1 bar '<' 1.0?

How is the above easier to read than

emerge >=foo-1.1 <bar-1.0

?

I think your example is working against you.

The current syntax is much easier to read than the quote-and-whitespace-tracking horror of your example :-P

Alex | wired

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

On Sat, 22 Sep 2012 20:11:48 +0300
Alex Alexander <wired@gentoo.org> wrote:

> On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:
> >
> > emerge 'foo >= 1.1' 'bar < 1.0'?
> > emerge foo '>=' 1.1 bar '<' 1.0?
>
> How is the above easier to read than
>
> emerge >=foo-1.1 <bar-1.0

Did you even test it? That would create '=foo-1.1' and then fail trying
to read 'bar-1.0'. It's rather:

emerge '>=foo-1.1' '<bar-1.0'

> I think your example is working against you*.*
>
> The current syntax is much easier to read than the
> quote-and-whitespace-tracking horror of your example :-P

It's no less quoting than in the current case. And it could be simply
extended to supporting quoting-less syntax, e.g.:

emerge foo -gt 1.1 bar -lt 1.0

--
Best regards,
Michał Górny

On Sep 22, 2012 8:25 PM, "Michał Górny" <mgorny@gentoo.org> wrote:

>

> On Sat, 22 Sep 2012 20:11:48 +0300

> Alex Alexander <wired@gentoo.org> wrote:

>

> > On Sep 22, 2012 7:38 PM, "Michał Górny" <mgorny@gentoo.org> wrote:

> > >

> > > emerge 'foo >= 1.1' 'bar < 1.0'?

> > > emerge foo '>=' 1.1 bar '<' 1.0?

> >

> > How is the above easier to read than

> >

> > emerge >=foo-1.1 <bar-1.0

>

> Did you even test it? That would create '=foo-1.1' and then fail trying

> to read 'bar-1.0'. It's rather:

>

> Â* emerge '>=foo-1.1' '<bar-1.0'

Yes, you are right, still much easier to read than your example tho.

Testing things is limited to very important stuff atm, I only have an android phone and intermittent 3g available and ssh without a real kb is a pain :-)

> > I think your example is working against you*.*

> >

> > The current syntax is much easier to read than the

> > quote-and-whitespace-tracking horror of your example :-P

>

> It's no less quoting than in the current case. And it could be simply

> extended to supporting quoting-less syntax, e.g.:

>

> Â* emerge foo -gt 1.1 bar -lt 1.0

I still find whitespace inappropriate for this kind of things. You are trying to replace a single atom that instantly gives you all required information with a format that does not clearly separate atoms, IMHO anyway :-)


Alex | wired

oops, didn't reply to the list. re-sending

On Sat, 2012-09-22 at 19:19 +0200, Michał Górny wrote:
> On Sat, 22 Sep 2012 10:05:41 -0700

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

Oh, I considered it for the past 4 hours before responding. Got nothing
in favour of it.

The current atom format and syntax in CONSISTENT throughout the configs,
and PM code. This proposal would split that in two, configs, ebuilds
one format, everything else the old.

quote "
Mine is easily incorporated into the PM; it is just a change
in a single place splitting and parsing the tokens.
"
That is unless you also change all the code to the new format and a new
data type.

I have written *DEPEND processing code (porthole's grahical Dependencies
view) and worked on code in portage, pkgcore, gentoolkit, gpytage,...
all working with the current atom syntax. This proposed change would
require all those tools and more to be refactored too!

So, to throw your words back at you:

This proposal was submitted ... "without even caring enough to consider
them before writing."


enough said.
--
Brian Dolbec <dolsen@gentoo.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/22/2012 09:55 AM, 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.
>
>
> 2. With long package names and versions, it becomes hard-to-read.
>
> Consider the following:
>
>> =dev-foo/bar-very-long-my-name-is-4-beta-17
>
> Where does the version number start? And yes, this is a valid
> package name to our rules.
>
>
> 3. Some potentially colliding package names are disallowed.
>
> A package name can't end up with something looking like version.
> Thus, if upstream names package:
>
> frobnicator-11
>
> We need to rename it in the tree, effectively losing the ability
> to follow upstream naming and introducing a bunch of unnecessary
> MY_P, S variables.
>
>
> 4. Adding, removing and changing versions is not friendly at all.
>
> Consider the following dep:
>
>> =dev-foo/bar-bas-bat-11.2.4_alpha
>
> Now, you want to bump the dep to 11.3. You need to find the
> version number, and modify it. Depending on the configuration, ^w
> is going to eat the whole package name or just a single component.
>
> Then, you want to remove the whole version. You need to first
> remove the version number, making sure it doesn't eat a bit of
> package name as well. Then, you have to go back to the beginning of
> the string, and remove the operator.
>
> Or you want to add a version. That one is simpler -- you just need
> to go to one end of the dep, add the operator, then to the other,
> and add the version.
>
>
> The fore-mentioned problems could be solved through introducing a
> more natural dependency syntax:
>
> PACKAGE-NAME [[*WSP] VERSION-OP [*WSP] PACKAGE-VERSION]]
>
>
> This way:
>
> 1. It follows exactly how people are reading it:
>
> PACKAGE-NAME [is VERSION-OP than PACKAGE-VERSION]
>
> 2. It is always clear what is the version, and what is not.
> Additionally, it allows you to introduce whitespace to increase
> readability even more:
>
> dev-foo/bar-very-long-my-name-is-4-beta >= 17
>
> 3. The optional (version dependency) part is at one side of the
> string, so it is easy to add, change or remove. Two times ^w and
> done!
>
> 4. It follows the syntax used by bash (for conditionals),
> pkg-config -- it is more natural in the environment.
>

KISS is not just about simplicity of a system, but also about
simplicity of changes and how big the gain is when the changes are not
simple.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQXhRmAAoJEFpvPKfnPDWzFJoH/jzjfVtHzbv3VUPJYl4WZSkq
ztNaFp8SPSeMS10sM48Pt2l3JkHnOlN8hiXS4zq9Gy9VLKT3rk P94h8g3Gmh8biP
pcHxGEpZOFV5ATuI2MNBDrF7LI8S0eVoOkutEQPAUwmI8NRzrj 0DpEwYlmsUDxwE
aD5vtMWLl02X6dnZfdLUN/zBo/T3jNWuLUyPmKWwB7qkIH+2W0y3ZxdBJmdA4VYl
ImrIM7RAhUgBb3cPtmloPt7rfYH/AGoS1O2M6eEZo1N2TmeZ4YwwciOmYfZrHWkc
AZzGs9yt0ElMkZrNNdHZlblyQhdZJ8xO2WhJrvmeG+HtwUJgtx DtYbowkkunLoM=
=5PkR
-----END PGP SIGNATURE-----