Summary: | [Feature Request] add ebuild's mtime support to eix | ||
---|---|---|---|
Product: | Portage Development | Reporter: | r01 <crquan> |
Component: | Tools | Assignee: | Stefan Schweizer (RETIRED) <genstef> |
Status: | RESOLVED LATER | ||
Severity: | enhancement | CC: | emilbeinroth, martin |
Priority: | Lowest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sourceforge.net/tracker/index.php?func=detail&aid=1901995&group_id=128101&atid=710611 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
r01
2008-03-03 08:20:41 UTC
(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. |