FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

LinkBack Thread Tools
Old 09-22-2012, 07:51 PM
Luca Barbato
Default A more natural (human-friendly) syntax for dependencies

Old 09-22-2012, 07:52 PM
Luca Barbato
Default A more natural (human-friendly) syntax for dependencies

Alex Alexander <wired@gentoo.org> wrote:

>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
>> 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

Old 09-25-2012, 11:41 PM
Brian Harring
Default A more natural (human-friendly) syntax for dependencies

On Sat, Sep 22, 2012 at 07:19:09PM +0200, Micha?? G??rny wrote:
> 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:
> > >
> > >
> > > 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.

It requires none of those things you claim.

I know this since I actually wrote patches for it already.

You should know this since you responded to that exact email, and
have been very active in that thread. I laid out exactly how this
plugged into our existing design and posted patches proving it.

Phrased as nicely as I can, you're trolling, poorly at that. Please

Reiterating it again for others who weren't as active in that thread,
patches are here:

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

You really need to do a walk through portage internals.

All ebuild based parsers are whitespace based parsing; the sole
exception is for src_uri's -> file rename, and by large that code is a
bit icky for each; in portages case, doubly so frankly
(pkgcore/paludis use a reversible iterator design in that case; less
icky, but it throws off the normal flow ).

This isn't a simple change for the PM; worse, it'll require two parse
tree codebases since trying to inline your notion in would fuck the
code up something fierce in terms of maintenence/flow.

If you'd like to argue that, I'd suggest you take pkgcore and modify
it for your intent (the parse code is pkgcore/ebuild/conditionals.py;
it's the simplest but full implementation out there imo, thus the
suggestion), while preserving parsing support for the old format;
just the python side, you don't need to do the c extension.

Post that patch and prove it; else... bluntly, you're arguing w/
authors about their own code. That usually isn't a scenario people
win. Some authors may be retards, hell, I may be, but I'm not wrong
on that section of code across the managers.

> > 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.

Just kicking the corpse to make damn sure it stays down, here's the
flaws I saw pretty much immediately in reading the first email; if an
hour was spent, I'm sure worse issues could be found.

*) cocks up emerge invocation. Previously `emerge
=dev-util/diffball-1`; your proposal, `emerge 'dev-util/diffball =
1'`. You argue "well you already have to quote for > or <"; thing is,
we don't have to quote for equals, and you now require it- globbed
versions, same thing.

*) If you argue "emerge should just collapse the args if given
`emerge dev-util/diffball = 1`, then I suggest *you* write that code,
and maintain it. It'd take a strong council action before I did that
in pkgcore. I think it's that level of wrong.

*) The proposal completely overlooked profiles. We'd have to
use the old form through out the entirety of the profiles. Woot,
maintaining two dep syntax/parse trees indefinitely...

* *) This requires changing the parsing rules of every single atom
based file in the profile tree. Anything use related
(package.use.mask) is whitespace split; not anymore it ain't. Code
duplication baby, lots of it.

*) The proposal ignores metadata/updates; more importantly, updates
are unversioned- we have no EAPI awareness in there. Meaning updates
would have to be the old form indefinitely.

*) The proposal completely ignored slot deps, repository deps, use
deps. You're arguing thus:

sys-apps/portage[build] >= 2.1
sys-apps/portage:0[build] =~ 2.2
sys-apps/portage::gentoo <= 2.2

*) This force duplication of atom parsing implementations; currently,
they all basically extract a cpv out of it if '<>=~' are seen; if
those operators aren't there, they split on '/'. Either the PM would
have to maintain duplicate parsing pathways/validation, or it would
(most likely) collapse your form down into the old form since we
already have well tested code that handles that.

*) This doesn't address profiles/news at all. I expect complications
to ensue there too, especially considering... wait for it... the atoms
in use there aren't EAPI versioned. Meaning old form is required

Again, I suggest you read up on the guts of existing package managers;
read he source. Additionally, please at least do a basic validation
of the notion before just throwing it at the dev ml; it may not matter
to you, but that's 21 more emails people have to read due to the basic
legwork not being done.


Thread Tools

All times are GMT. The time now is 03:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org