ebuild file's mtime is an important field, this filed can represent the time of when gentoo add support to new upstream packages, store this filed to eix index file could be very useful: For example: someone want to install impi related tools, and "eix ipmi" returns several results, ipmitool/ipmiutil/freeipmi/openipmi, these results almost provide the same functions wanted, but it confused with "what's the best ipmi toolkit?", the user has to try to use every package or find some comparison articles on them, those are all not easy. Currently, the best solution to these similar solution is like the debian popularity-contest, from the contest result we can learn the best toolkit, but without popularity-contest, what's the simplest coding solution to relieve that confusion? if "eix ipmi" could give mtime of every available versions, the selection would be easier, right? Further more, the results can be sorted by mtime. In fact, every time I compare the results' ebuild mtime manually. In addition, I found I often browse the packages.gentoo site(http://packages.gentoo.org/), just for its latest packages, if eix has mtime feature, this can be easily implemented, after portage synced and update-eix, "eix --latest 10" could give 10 lasted ebuild supported by gentoo, let packages.gentoo's function runs locally, BTW, from https://projects.gentooexperimental.org/eix/: "If you have questions, comments or feature requests feel free to contact the developers in #eix on irc.freenode.net" But I found no one in that irc channel, what's wrong with it? I cannot even find a mailing list about eix developments, so I post here to interrupt someone, please play attention.
(In reply to comment #0) > ebuild file's mtime is an important field But this field is not contained in the portage metadata. There are several reasons why only (parts of) portage metadata is contained in the eix database (to name the two most important: speed for building the database; consistency of various cache method). So unless the mtime becomes part of portage metadata, this information will not be supported by eix. BTW: mtime is rather misleading, since most changes are adding or removing some architecture. > [...] #eix on irc.freenode.net" Thanks. I am currently eliminating all mentioning of this meanwhile dead irc channel.
(In reply to comment #1) > [...] supported by eix. But compare the packages.gentoo.org code (git://anongit.gentoo.org/packages.git/) and the eix: the packages software's function is similar to eix: 1. they both use a backend to generate an index file (update-eix and dbgenerator/core.py); 2. they both provide a query interface to search something (eix and web/controller.py), just different interface, a command line search interface and a web search interface, then say the code, the packages.gentoo code of update index is dbgenerator/core.py, it use dbgenerator/backend.py to collect ebuild's information: efilename = package + "-" + pkg.fullver + ".ebuild" epath = pjoin(self.work_repo_location, category, package, efilename) mtime = file_mtime(epath) sha1 = file_sha1(epath) yield (pkg.versioned_atom.fullver, keyword_dict, mtime, sha1) the method file_mtime is just call to int(os.stat(path).st_mtime), so now my question is: 1. Since packages can do well with mtime, Why eix not? 2. What's the difference between eix and packages? BTW, I think the "Additional Comments:" textarea input box too small, anyone agree? http://bugs.gentoo.org/show_bug.cgi?id=212242
mtime() in thousands of difference directories costs quite some time unless the directories are in harddisk cache. For packages.gentoo.org it doesn't make much of a difference whether the scanning costs 20 seconds or 2 minutes, for a user of update-eix it does (moreover, packages.gentoo.org will probably usually *have* the directories in harddisk cache). Next, there is the consistency problem: If you use e.g. the sqlite-backend, all which update-eix needs is the sqlite file (and the portage config files which actually I consider inconsistent either but which is necessary for setting the mask-flags; otherwise diff-eix could not show changes in masks). Anyway, with the required feature, update-eix would need *in addition* the whole portage tree. (the sqlite-backend is only an example; a similar remark holds for all other "true" cache backends). Sure, in theory, one could make the feature optional for those users not caring about the update time and consistency. But it would also considerably increase the database size for anybody, and eix is dying the feature death anyway (e.g. most users do not even know about the different cache methods). Finally, as mentioned earlier, mtime is not very reliable. Not only from the point of view that it is not a measure on the activity on a project, but what is worse: It works currently "by accident" for the main tree, but e.g. for overlays (or prefix-portage) hosted by svn, it simply gives wrong information.
(In reply to comment #3) > Finally, as mentioned earlier, mtime is not very reliable. Not only from the > point of view that it is not a measure on the activity on a project, but what > is worse: It works currently "by accident" for the main tree, but e.g. for > overlays (or prefix-portage) hosted by svn, it simply gives wrong information. ebuilds' mtime in portage tree recorded the last change time by occasion indeed, just because it's transfered by rsync method, that would transfer the mtime too, but other portage overlay as svn/cvs/git/... all do not transfer the mtime, they must be judged by their commit history, all will be too time consuming, Alternatively, we can add mtime support to portage tree only, the official portage tree always transferred by rsync (really?), that would keeps the mtime. Or we can add mtime support to eix instead of update-eix, that means stat the eix search result ebuild file's mtime on the fly, do not store it to index file, how about this?
(In reply to comment #4) > Alternatively, we can add mtime support to portage tree only which solves none of the problems mentioned earlier > eix search result ebuild file's mtime on the fly and thus decrease the speed of eix to that of equery. Unless mtime becomes part of the portage metadata, eix will not support it.
we first need portage support for this. Feel free to ask the portage devs for that.
