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 <dol...@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.
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 desist. Reiterating it again for others who weren't as active in that thread, patches are here: http://dev.gentoo.org/~ferringb/unified-dependencies/patches/ > 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 indefinitely. 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. ~harring
