"For bugreports, please use the gentoo bug system" It would be great to read changelog/metadata from a package through eix by "eix --changelog/--metadata $package" (if there are multiple packages because $package is not an unique packagename or pattern which suits only one package, there should be a "multiple choice" from 1) to x) like in etc-update (if there are more than one config to be changed)).
(In reply to comment #0) > "For bugreports, please use the gentoo bug system" Is there still a place where I forgot to fix this? It is perhaps not always necessary to bother gentoo's bug wranglers... The man page in current versions is corrected: For bugreports use either http://sourceforge.net/projects/eix/ or Gentoo's bugzilla http://bugs.gentoo.org/ > It would be great to read changelog/metadata from a package through eix > by "eix --changelog/--metadata $package" This is certainly not the job of the eix binary: eix's job is it to access its own database and solve problems for which that database is appropriate (for some tasks it is also necessary to access /var/db/pkg and some portage configuration files, but that's it). It makes no sense to store all metadata.xml/ChangeLogs in eix' database. So the appropriate solution for that task is to write an independent program (for ChangeLog probably a shell script, for metadata perhaps using some other language which can output the xml information in human-readable form); these scripts can e.g. parse the output of eix --only-names "${@}" eix --print PORTDIR eix --print PORTDIR_OVERLAY to find out the full package names and paths. However such a thing exists already in a more appropriate form than with eix package finding syntax: app-portage/gentoolkit For ChangeLogs there is equery c [-f|-l|...] pkg and for Metadata there is equery m [-x|-u|...] pkg Since also speed is not so important for that tasks, I see no reason to duplicate this function - IMHO equery does a good job.
http://eix.sourceforge.net/ on this page there's only the gentoo bugzilla mentioned ok, i supposed eix to be a Swiss army knife for portage and i missed this function in it. but if the task of eix is to provide operations using its own db, then please close as invalid and i'll use equery :)
(In reply to comment #2) > ok, i supposed eix to be a Swiss army knife for portage It has become this in a sense, because I missed too many things like eix-test-obsolete or versionsort in standard portage tools, and eix had all functions needed to implement them. Anyway, it was meant to be a package search tool, and IMHO it is more a disadvantage of portage than an advantage of eix that eix' role was extended. There are several more basic things which are not supported by eix, most importantly no handling of USE-flags. Closing as WONTFIX.
