The suggested way would be nicer, i think. Also, i dont think the way it is displayed was chosen on purpose, which i why i file this bug. Or, possibly, some connecting words like "A or B" or something similar might be good. Reproducible: Always Steps to Reproduce: 1. emerge esarch 2. esearch binutils Actual Results: * sys-devel/binutils Latest version available: 2.15.90.0.1.1-r3 Latest version installed: 2.15.90.0.1.1-r3 Size of downloaded files: 10,874 kB Homepage: http://sources.redhat.com/binutils/ Description: Tools necessary to build programs License: || ( GPL-2 LGPL-2 ) Expected Results: * sys-devel/binutils Latest version available: 2.15.90.0.1.1-r3 Latest version installed: 2.15.90.0.1.1-r3 Size of downloaded files: 10,874 kB Homepage: http://sources.redhat.com/binutils/ Description: Tools necessary to build programs License: GPL-2 LGPL-2
Hi, esearch was basically intended to show exactly the same as "emerge -s". If you look at "emerge -s ^binutils$", you'll see, that emerge show's the same output, which is really confusing for non-programmers, I admit. The problem is, that I would need to write a parser for these license-strings, which would certainly slow down eupdatedb again. I will try to implement such a feature, but I cannot promise, that it will appear in esearch. David
at this point in time i would say dont do it in esearch but do it in portage i like having esearch being fast :)
So... suggestions on how to humanize it? Convulted example: LICENSE="|| ( foo ( bar baz ) ( bar use? ( foo ) ) )" -> foo OR ( bar AND baz ) OR ( bar AND foo IF USE="use" ) or rewriting the same: LICENSE="|| ( foo ( bar || ( baz use? ( foo ) ) ) )" -> foo OR ( bar AND ( baz OR foo IF USE="use" ) ) That's probably about the best I can do... I've probably been looking at DEPEND strings for too long, but the original LICENSE form seems easiest to read to me. ;)
As there is the possibility for more complex license strings (don't think we have any real complex, but you never know with all these weird packages) output probably will get confusing one way or the other, especially when there are use-dependencies. Current output has the advantage that it's basically described in ebuild(5) with the DEPEND syntax. So I don't think changing it to something "more readable" is really a good idea in the long run.
